Bug 110302 - [bisected][regression] piglit egl-create-pbuffer-surface and egl-gl-colorspace regressions
Summary: [bisected][regression] piglit egl-create-pbuffer-surface and egl-gl-colorspac...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Emil Velikov
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mesa-19.1
  Show dependency treegraph
 
Reported: 2019-04-01 18:42 UTC by Clayton Craft
Modified: 2019-06-10 13:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Passing test output (5.34 KB, text/plain)
2019-05-29 22:22 UTC, Andrés Gómez García
Details
Failing test output (5.43 KB, text/plain)
2019-05-29 22:23 UTC, Andrés Gómez García
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clayton Craft 2019-04-01 18:42:03 UTC
The following piglit tests fail on all Intel GPUs:

piglit.spec.egl 1_4.eglcreatepbuffersurface and then glclear

stdout

> /tmp/build_root/m64/lib/piglit/bin/egl-create-pbuffer-surface -auto
> Probe color at (0,0)
>   Expected: 1.000000 0.000000 1.000000 1.000000
>   Observed: 1.000000 1.000000 1.000000 1.000000



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)


commit c5c38e831ee8113cf97fb5308fbb687464ae2f0e
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Mon Aug 6 07:05:19 2018 -0400

    mesa: implement ARB/KHR_parallel_shader_compile
Comment 1 Marek Olšák 2019-04-02 13:04:58 UTC
I think the problem is that the es1 glapi dispatch broke after adding a new function.
Comment 2 Juan A. Suarez 2019-05-13 16:25:56 UTC
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" }
Comment 3 Juan A. Suarez 2019-05-23 08:52:59 UTC
This bug is a blocker for Mesa 19.1.0.


Is there any progress here?
Comment 4 Marek Olšák 2019-05-25 01:20:03 UTC
It's a bug in the glapi dispatch table for GLES 1.x. It was randomly uncovered by the commit.
Comment 5 Juan A. Suarez 2019-05-29 13:25:49 UTC
Marek, do you have a fix for it?
Comment 6 Andrés Gómez García 2019-05-29 22:16:49 UTC
(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.
Comment 7 Andrés Gómez García 2019-05-29 22:22:38 UTC
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.
Comment 8 Andrés Gómez García 2019-05-29 22:23:33 UTC
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.
Comment 9 Andrés Gómez García 2019-05-29 22:30:47 UTC
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.
Comment 10 Marek Olšák 2019-05-30 01:12:21 UTC
The master branch doesn't have this issue. I don't know what fixed this in master.
Comment 11 Andrés Gómez García 2019-05-30 11:45:51 UTC
(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?
Comment 12 Marek Olšák 2019-05-30 23:42:24 UTC
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"
Comment 13 Mark Janes 2019-05-31 00:08:01 UTC
Emil, you are listed on the thread the Marek referenced.  Do you know what needs to change?
Comment 14 Mark Janes 2019-05-31 01:03:45 UTC
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.
Comment 15 Emil Velikov 2019-05-31 09:59:17 UTC
I have a patch to fix this and patch future problems earlier. Will polish and send out in the weekend.
Comment 16 Tapani Pälli 2019-05-31 10:40:54 UTC
(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.
Comment 17 Andrés Gómez García 2019-05-31 11:59:33 UTC
(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
Comment 18 Emil Velikov 2019-06-05 16:26:39 UTC
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
Comment 19 Juan A. Suarez 2019-06-06 13:57:57 UTC
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.
Comment 20 Juan A. Suarez 2019-06-06 14:12:38 UTC
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
Comment 21 Emil Velikov 2019-06-07 15:50:47 UTC
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
Comment 22 Emil Velikov 2019-06-07 16:33:25 UTC
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
Comment 23 Emil Velikov 2019-06-07 17:35:27 UTC
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
Comment 24 Juan A. Suarez 2019-06-09 18:20:00 UTC
Emil, now everything works fine.

Thanks
Comment 25 Emil Velikov 2019-06-10 13:27:48 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.