[Mesa-dev] [PATCH v6.2] egl: Allow creation of per surface out fence

[Marathe, Yogesh]

> -----Original Message-----
> From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
> Sent: Friday, September 8, 2017 11:03 PM
> To: Antognolli, Rafael <rafael.antognolli at intel.com>
> >> > > Isn't this strange? Can someone please comment?
> >> > >
> >> > In all fairness there was a few wtf moments as Mark mentioned the
> >> > issue. As on a quick look "it cannot happen" :-\
> >> >
> >> > One way is to add some printfs "debugging" across the board and
> >> > check with Mark if he can run (only?) the affected test on the CI.
> >> >
> >>
> >> Number of tests failing on CI due to this are huge, any 'one' can be
> >> picked up. I do have my CI branch setup now but I don’t think I can
> >> use it for debugging (not advised).  I'll sync up with Mark again. Just wanted a
> confirmation, I'm not missing something obvious. Thanks.
> >
> > Hi Yogesh,
> >
> > I replied to you already when you messaged in private, the error is
> > not related to the kernel returning true for that, it's related to a
> > memory corruption caused by wrong use of the dri2_surf_init inside
> > platform_x11_dri3.c. Quoting myself:
> >
> > "More specifically, it looks like this test fails every time:
> >
> > glcts -n
> > dEQP-EGL.functional.query_context.get_current_context.rgb888_window
> >

This passes for me. That’s what confused me again. how is that possible?

Output:

Writing test log into TestResults.qpa
dEQP Core git-dfcb8e870438f6f2bfe71d4bb63d43120debb3a3 (0xdfcb8e87) starting..
  target implementation = 'X11 EGL'

Test case 'dEQP-EGL.functional.query_context.get_current_context.rgb888_window'..
  Pass (Pass)

DONE!

Test run totals:
  Passed:        1/1 (100.0%)
  Failed:        0/1 (0.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)

> > I see several valgrind warnings inside platform_x11_dri3.c. I believe
> > you are probably accessing the dri2_surf before it was allocated, or
> > after it was freed..."
> >
> > When I tested this back then, the "out_fence_enable" (or whatever was
> > called) in dri2 was false, but after a couple runs it would become a
> > bogus number, which also points to memory corruption.
> >
> > I suggest ignoring the kernel and focusing on valgrind debugging.
> >
> Nicely spotted there Rafael.
> 
> The issue is that the dri3 surface primitive wraps around _EGLSurface.
> Thus as we reference the new variables we effectively write onto the
> loader_dri3 bits. And at a later stage the dri3 loader code toggles those to "use
> out fence = true".

I will check this with valgrind.

> 
> -Emil