Re: trouble with GL and GLES surfaces

On Fri, Dec 29, 2017 at 05:26:32PM +0100, Theo Veenker wrote:
> Hi all,
> 
> I decided to spend some time on playing with cairo's GL backend. First I
> looked at 1.15.11 (this is all under Linux Mint 18 64-bit, kernel 4.4.0-98,
> X.Org 1.18.4).

Thanks for testing the gles code.

> Cairo 1.15.11 configured with --enable-gl worked for me. I could use
> cairo_gl_surface_create_for_window(), cairo_gl_surface_create() and
> cairo_surface_create_similar() as advertised.
> 
> However when configured with --enable-glesv2 I ran into some problems:
> - Cairo_gl_surface_create_for_egl() is fine, but both
> cairo_gl_surface_create() and cairo_surface_create_similar() consistently
> fail with CAIRO_STATUS_DEVICE_ERROR.

Unfortunately CAIRO_STATUS_DEVICE_ERROR is used as kind of a generic
"something's wrong" error message.  Could be anything from a driver
issue on up.  I wouldn't rule out some flaw in my patch, either,
although if you're seeing problems creating gl surfaces on 1.14 too,
then might be a deeper issue.

I verified glesv2 worked and generated graphics for me identically
between 1.14 and 1.15 before landing, although it's possible you're
setting up the surfaces in a different way that I didn't test.  If you
can give me the snippet of code you're using to set things up, or a
minimal test case or somesuch, I can examine it compared with my own and
see if I can see the same issue as you and maybe isolate why.

> - Copying a (any) surface using cairo_paint() into a surface created by
> cairo_gl_surface_create_for_egl() causes a core dump. That is, at first it
> sometimes looks OK. And then when I trigger a redraw it segfaults. This does
> not happen with 1.14.12. Valgrind consistently shows it is accessing
> location 0xC. Here's a snippit of the valgrind log:
> ==24122== Process terminating with default action of signal 11 (SIGSEGV): dumping core
> ==24122==  Access not within mapped region at address 0xC
> ==24122==    at 0x5AF0562: _cairo_gl_pattern_texture_setup (cairo-gl-operand.c:292)

This appears to correspond with this chunk of code:

    surface = (cairo_gl_surface_t *)
        _cairo_gl_surface_create_scratch (ctx,
                                          CAIRO_CONTENT_COLOR_ALPHA,
                                          extents->width,
                                          extents->extents->height);

Which is basically just a wrapper around _create_scratch_internal, that
calls _cairo_gl_surface_create_scratch_for_texture and then
glTexImage2D.  Hard to make any guesses from there.  A full backtrace
with debug symbols compiled in might give more useful information.

"address 0xC" sounds like an invalid pointer, either uninitialized
memory or an incorrect assignment or something.

> ==24122==    by 0x5AF0562: _cairo_gl_operand_init (cairo-gl-operand.c:555)
> ==24122==    by 0x5AEC03F: _cairo_gl_composite_set_source (cairo-gl-composite.c:150)
> ==24122==    by 0x5AEC03F: _blit_texture_to_renderbuffer (cairo-gl-composite.c:108)
> ==24122==    by 0x5AEC1BC: _cairo_gl_composite_init (cairo-gl-composite.c:1278)
> ==24122==    by 0x5AF3B43: copy_boxes.part.0 (cairo-gl-spans-compositor.c:342)
> ==24122==    by 0x5A9FDBC: upload_boxes (cairo-spans-compositor.c:518)
> ==24122==    by 0x5A9FDBC: composite_aligned_boxes (cairo-spans-compositor.c:630)
> ==24122==    by 0x5A9FDBC: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)
> ==24122==    by 0x5A9FE7D: clip_and_composite_boxes (cairo-spans-compositor.c:901)
> ==24122==    by 0x5AA0198: _cairo_spans_compositor_mask (cairo-spans-compositor.c:999)
> ==24122==    by 0x5A57578: _cairo_compositor_paint (cairo-compositor.c:65)
> ==24122==    by 0x5AABAF0: _cairo_surface_paint (cairo-surface.c:2198)
> ==24122==    by 0x5AF6108: _cairo_gl_surface_draw_image (cairo-gl-surface.c:1049)
> ==24122==    by 0x5AF39FA: draw_image_boxes (cairo-gl-spans-compositor.c:311)
> ==24122==    by 0x5A9FDEF: upload_boxes (cairo-spans-compositor.c:514)
> ==24122==    by 0x5A9FDEF: composite_aligned_boxes (cairo-spans-compositor.c:630)
> ==24122==    by 0x5A9FDEF: clip_and_composite_boxes.part.11 (cairo-spans-compositor.c:882)

> Then I tried the same thing using cairo 1.14.2. Here I don't see any of the
> problems mentioned above. However I did notice a different problem with the
> regular GL (non-GLES) backend:
> - It appears I can't use a GL surface (as created by
> cairo_gl_surface_create() or cairo_surface_create_similar()) as a source for
> cairo_set_source_surface(). No error is reported by
> cairo_set_source_surface() or cairo_paint(). This does however work
> correctly when configured with --enable-glesv2.

As far as I know that *should* work.  Is there a possibility that
there's an error in your setup code?  That could explain a lot of the
problems you've described.  Again, if you can send me a sample
reproducer I can take a deeper look.  If it does turn out to be a
regression in the new code, your example could help me isolate it and
improve my own tests to cover that case.

> I did not test the GLESv3 backend as I have no idea where to get the glesv3
> package referred to by cairo.pc.

The glesv3 support may be installed with glesv2.  You can look in
/usr/include and /usr/lib to see if the gles 3 stuff is there, or just
try --enable-glesv3.  I doubt it'll make a difference for your problem
though, but might be broken in a more interesting way.

Bryce

> Theo
> 
> -- 
> Theo Veenker  |  Beexy - Behavioral Experiment Software
> +31(0)524-541531  |  +31(0)6-42525777 mobile
> [email protected]  |  www.beexy.nl
> -- 
> cairo mailing list
> [email protected]
> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo