Steps: 1. Download chrome and install it on your Ubuntu, https://www.google.com/chrome/?platform=linux&extra=devchannel; 2. Open https://www.khronos.org/registry/webgl/sdk/tests/conformance2/transform_feedback/transform_feedback.html?webglVersion=2&quiet=0 3. First time open link, all cases will be successful. Please click refresh button of chrome, some cases fail. Notes: 1. I could only reproduce it on mesa git master, could not reproduce on system driver(Ubuntu 17.10). May our latest code introduced some regression? 2. The case may be related with https://bugs.freedesktop.org/show_bug.cgi?id=106810 3. Chrome will cache program binary, the second time run page, chrome will call glProgramBinary to avoid re-compile shaders and re-link program. 4. This failed cases verify glGetProgramiv to get tranform feedback varyings number, and getTransformFeedbackVarying to get transform feedback's size, type and name. But current program seems be without transform feedback varyings information. 5.I had checked mesa code. For example, glProgramBinary triggers read_xfb function to re-serialize binary, creates gl_transform_feedback_info object, which also has a member named "NumVarying", if the program binary has two tranform feedback varyings, "NumVarying" value is 2. Then call glGetProgramiv to get tranform feedback varyings number in shaderapi.c, the value is got from "NumVarying", which is a member of TransformFeedback of gl_shader_program. I found that glProgramBinary implemetation in mesa did not update transform feedback varyings number from gl_transform_feedback_info object to TransformFeedback object.
Any chance you might be able to write a small piglit test that shows the bug? For example: https://cgit.freedesktop.org/piglit/commit/?id=f1dc46ddf8c1
FYI on my Fedora machine, there are failures with this test already with Mesa 17.3.6 so at least some of these are pretty old issues, before shader cache was turned on.
(In reply to Tapani Pälli from comment #2) > FYI on my Fedora machine, there are failures with this test already with > Mesa 17.3.6 so at least some of these are pretty old issues, before shader > cache was turned on. It sounds like this is possibly an interaction with ARB_get_program_binary, and not the shader cache. Hmm, except ARB_get_program_binary wasn't really supported until 18.0. So, if failures go back to 17.3, then maybe it is something else.
I've noticed that if I skip uniform removal in opt_dead_code (even builtin uniforms), then this test passes. I have no idea why this is though. I have been running chrome with following arguments: "--use-gl=egl --disable-gpu-program-cache --disable-gpu-shader-disk-cache".
(In reply to Tapani Pälli from comment #4) > I've noticed that if I skip uniform removal in opt_dead_code (even builtin > uniforms), then this test passes. I have no idea why this is though. I have > been running chrome with following arguments: "--use-gl=egl > --disable-gpu-program-cache --disable-gpu-shader-disk-cache". Hmm it seems that these flags are not really honored by Chrome though, if I 'disable' program binary by just returning from program binary functions then there are far less failures ... so this is probably about program binary after all.
Fix proposal sent here: https://lists.freedesktop.org/archives/mesa-dev/2018-June/197678.html
(In reply to Tapani Pälli from comment #6) > Fix proposal sent here: > https://lists.freedesktop.org/archives/mesa-dev/2018-June/197678.html Hi, Tapani, thank you for your patch, seems that this patch could resolve the bug, I will double check it tomorrow. Will you merge this patch to mesa master?
(In reply to xinghua from comment #7) > (In reply to Tapani Pälli from comment #6) > > Fix proposal sent here: > > https://lists.freedesktop.org/archives/mesa-dev/2018-June/197678.html > > Hi, Tapani, thank you for your patch, seems that this patch could resolve > the bug, I will double check it tomorrow. > Will you merge this patch to mesa master? If others (reviewers) agree that this is correct, then yes.
(In reply to Jordan Justen from comment #1) > Any chance you might be able to write a small piglit test > that shows the bug? For example: > > https://cgit.freedesktop.org/piglit/commit/?id=f1dc46ddf8c1 Hi, Jordan, Tapani had already submitted a patch for this issue. Do I still need to write a test in piglit.
(In reply to xinghua from comment #9) > (In reply to Jordan Justen from comment #1) > > Any chance you might be able to write a small piglit test > > that shows the bug? For example: > > > > https://cgit.freedesktop.org/piglit/commit/?id=f1dc46ddf8c1 > > Hi, Jordan, Tapani had already submitted a patch for this issue. Do I still > need to write a test in piglit. No its ok I made Tapani write a piglit test to go along with the patch :P
--- 8< --- commit ab2643e4b06f63c93a57624003679903442634a8 Author: Tapani Pälli <tapani.palli@intel.com> Date: Thu Jun 14 11:10:20 2018 +0300 glsl: serialize data from glTransformFeedbackVaryings While XFB has been enabled for cache, we did not serialize enough data for the whole API to work (such as glGetProgramiv). Fixes: 6d830940f7 "Allow shader cache usage with transform feedback" Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106907 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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.