I think the problem is that the es1 glapi dispatch broke after adding a new function.

I think the same commit affects also these 2 piglit tests:

spec@egl 1.4@largest possible eglcreatepbuffersurface and then glclear

/bin/egl-create-largest-pbuffer-surface -auto
libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering.
Probe color at (0,0)
  Expected: 1.000000 0.000000 1.000000 1.000000
  Observed: 1.000000 1.000000 1.000000 1.000000
PIGLIT: {"result": "fail" }



spec@egl_nok_texture_from_pixmap@basic

./bin/egl-nok-texture-from-pixmap -auto
EGL_Y_INVERTED_NOK: TRUE
libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering.
Probe color at (50,50)
  Expected: 0.500000 0.000000 0.500000 1.000000
  Observed: 0.400000 0.000000 0.000000 1.000000
PIGLIT: {"result": "fail" }

This bug is a blocker for Mesa 19.1.0.


Is there any progress here?

It's a bug in the glapi dispatch table for GLES 1.x. It was randomly uncovered by the commit.

Marek, do you have a fix for it?

(In reply to Clayton Craft from comment #0)

...

> piglit.spec.egl_khr_gl_colorspace.linear
> 
> stdout
> > /tmp/build_root/m64/lib/piglit/bin/egl-gl-colorspace -auto -fbo
> > Probe color at (0,0)
> >   Expected: 0.000000 0.300000 0.000000
> >   Observed: 0.501961 0.501961 0.501961
> > Probe color at (20,0)
> >   Expected: 0.000000 0.600000 0.000000
> >   Observed: 0.501961 0.501961 0.501961
> stderr
> > (none)

I've been playing a bit with this test. Indeed, it seems the glapi dispatch table for GLES 1.x. is broken (at least) after c5c38e831ee8113cf97fb5308fbb687464ae2f0e.

Created attachment 144374 [details]
Passing test output

Output from running:

# MESA_VERBOSE=all MESA_DEBUG=context /home/mesa/piglit/bin/egl-gl-colorspace -auto -fbo > good-3ad2a9b3fa.txt 2>&1

In a mesa compiled at the immediately previous commit to the offending one.

Created attachment 144375 [details]
Failing test output

Output from running:

# MESA_VERBOSE=all MESA_DEBUG=context /home/mesa/piglit/bin/egl-gl-colorspace -auto -fbo > bad-c5c38e831ee.txt 2>&1

In a mesa compiled at the offending commit.

The difference is:

# diff -uN good-3ad2a9b3fa.txt bad-c5c38e831ee.txt
--- good-3ad2a9b3fa.txt 2019-05-30 00:18:19.237415743 +0200
+++ bad-c5c38e831ee.txt 2019-05-30 00:18:28.441484427 +0200
@@ -49,8 +49,6 @@
 Mesa: glViewport 0 0 300 300
 Mesa: FLUSH_VERTICES in _mesa_LoadIdentity
 Mesa: glLoadIdentity()
-Mesa: FLUSH_VERTICES in _mesa_Ortho
-Mesa: glOrtho(0.000000, 300.000000, 0.000000, 300.000000, -1.000000, 1.000000)
 Mesa: FLUSH_VERTICES in _mesa_LoadIdentity
 Mesa: glLoadIdentity()
 Mesa: glClear 0x4000
@@ -80,13 +78,13 @@
 Mesa: FLUSH_VERTICES in _mesa_flush_vertices_for_blend_state
 Mesa: FLUSH_VERTICES in read_pixels
 Mesa: FLUSH_CURRENT in read_pixels
-Mesa: glReadPixels(20, 20, GL_RGBA, GL_UNSIGNED_BYTE, 0x5566061fe060)
+Mesa: glReadPixels(20, 20, GL_RGBA, GL_UNSIGNED_BYTE, 0x56238576fed0)
 Mesa: _mesa_update_state: (0x100008) ctx->Color, ctx->Array, 
 : Mesa debug output: FS SIMD8 shader: 14 inst, 0 loops, 308 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 224 to 176 bytes.
 : Mesa debug output: FS SIMD16 shader: 14 inst, 0 loops, 322 cycles, 0:0 spills:fills, Promoted 0 constants, compacted 224 to 176 bytes.
 Mesa: FLUSH_VERTICES in read_pixels
 Mesa: FLUSH_CURRENT in read_pixels
-Mesa: glReadPixels(20, 20, GL_RGBA, GL_UNSIGNED_BYTE, 0x5566061fe060)
+Mesa: glReadPixels(20, 20, GL_RGBA, GL_UNSIGNED_BYTE, 0x56238576fed0)
 Mesa: FLUSH_VERTICES in intel_dri2_flush_with_flags
 Mesa: FLUSH_VERTICES in _mesa_flush
 Mesa: FLUSH_CURRENT in _mesa_flush
@@ -97,4 +95,10 @@
 Mesa: _mesa_make_current()
 Mesa: _mesa_make_current()
 Mesa: _mesa_make_current()
-PIGLIT: {"result": "pass" }
+Probe color at (0,0)
+  Expected: 0.000000 0.300000 0.000000
+  Observed: 0.501961 0.501961 0.501961
+Probe color at (20,0)
+  Expected: 0.000000 0.600000 0.000000
+  Observed: 0.501961 0.501961 0.501961
+PIGLIT: {"result": "fail" }


--


Basically, what we can see is, in the offending commit, glOrtho doesn't get called.

Debugging with GDB, I see that piglit "correctly" gets the pointer to the glOrtho function but, upon calling, nothing really happens. If I set a breakpoint at the function, it doesn't stop. Basically, although the dispatch table returns a pointer, it seems the pointer is not correct.

The master branch doesn't have this issue. I don't know what fixed this in master.

(In reply to Marek Olšák from comment #10)
> The master branch doesn't have this issue. I don't know what fixed this in
> master.

This is still failing for me in current master (da26013eb7a216eea98b71ba6e8341a47834e3ec).

Could you point to the commit you tested, in case we have a divergence?

Ok. It looks like the master branch is broken too.

This mesa-dev thread contains more info:
"new dispatch generator broke with Marek's parallel compile commit"

Emil, you are listed on the thread the Marek referenced.  Do you know what needs to change?

FWIW, reverting the glvnd generator patches fixes the regressions.  Results will be displayed soon at:

https://mesa-ci.01.org/majanes/builds/255/group/63a9f0ea7bb98050796b649e85481845

The dEQP-EGL.functional.multithread.window_context result looks like a red herring.  There are intermittent failures for that test on mesa_master.

I have a patch to fix this and patch future problems earlier. Will polish and send out in the weekend.

(In reply to Mark Janes from comment #14)
> FWIW, reverting the glvnd generator patches fixes the regressions.  Results
> will be displayed soon at:
> 
> https://mesa-ci.01.org/majanes/builds/255/group/
> 63a9f0ea7bb98050796b649e85481845
> 
> The dEQP-EGL.functional.multithread.window_context result looks like a red
> herring.  There are intermittent failures for that test on mesa_master.

Yes, this is a separate issue. What comes to EGL multithread test failures, I've fixed these in Xlib and also have a vk-gl-cts WA for this, I think we should use the WA in CI until new release of Xlib happens.

(In reply to Marek Olšák from comment #12)

> This mesa-dev thread contains more info:
> "new dispatch generator broke with Marek's parallel compile commit"

For the sake of completing:

https://lists.freedesktop.org/archives/mesa-dev/2019-April/217458.html

The following series should fix the problem. Can you please try them on your end?

https://lists.freedesktop.org/archives/mesa-dev/2019-June/219861.html

I have problems to build the code after applying both patches:

 File "/home/igalia/jasuarez/mesa/src/mapi/glapi/gen/gl_XML.py", line 691, in process_element
    raise RuntimeError("Entry-point %s is missing offset in static_data.py. Add one at the bottom of the list." % (name))
RuntimeError: Entry-point MatrixLoadfEXT is missing offset in static_data.py. Add one at the bottom of the list.

After adding all the missing elements in static_data.py, now it builds correctly.

Still, the tests seems to be fail.

Calling

MESA_VERBOSE=all MESA_DEBUG=context ./bin/egl-gl-colorspace -auto -fbo

I still don't see glOrtho being called

Just rebased the series against master to include the EXT_dsa patch, and corresponding fix.

With the old series and this one the test passes on my end. The context debug also points out the entrypoint.

Juan can you double-check that your build produces debug output - IIRC some of the build-type toggles effectively disable it.

$ MESA_VERBOSE=all MESA_DEBUG=context DISPLAY=:0 .../egl-gl-colorspace -auto -fbo |& grep -i Ortho
Mesa: glOrtho(0.000000, 300.000000, 0.000000, 300.000000, -1.000000, 1.000000)
Mesa: FLUSH_VERTICES in matrix_ortho

v2 https://lists.freedesktop.org/archives/mesa-dev/2019-June/219933.html

Please double-check that the correct (new) libraries are picked at runtime. Quick how-to for libGL/libGLES*. 

$ LD_DEBUG=libs  $usual_command  |& grep libGL

The Intel CI also seems happy \o/
Juan, others feel free to merge the patches - I'm off for the weekend.

https://mesa-ci.01.org/evelikov/builds/35/group/63a9f0ea7bb98050796b649e85481845

Emil, now everything works fine.

Thanks

Thanks for the confirmation. Pushed the series to master.

commit a379b1c0ee31a792bba250cc466ad4b161a610ec
Author: Emil Velikov <emil.velikov@collabora.com>
Date:   Wed Jun 5 16:45:03 2019 +0100

    mapi: correctly handle the full offset table