Software versions: 4.4.0-040400rc4-generic OpenGL version string: 3.0 Mesa 11.2.0-devel (git-83e8e07) GPU hardware: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 00:02.0 VGA compatible controller [0300]: Intel Corporation Sky Lake Integrated Graphics [8086:1912] (rev 06) CPU hardware: x86_64 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz ----------------- Software versions: 4.3.0-rc3+ OpenGL version string: 3.0 Mesa 11.2.0-devel (git-83e8e07) GPU hardware: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5300 (Broadwell GT2) 00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:161e] (rev 06) CPU hardware: x86_64 Genuine Intel(R) CPU 0000 @ 0.60GHz ------------------ Software versions: 4.2.0-1-generic OpenGL version string: 3.0 Mesa 11.2.0-devel (git-83e8e07) GPU hardware: OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) CPU hardware: x86_64 Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz ----------------- CTS version: git@67ae88f31295 command: ./glcts --deqp-case=ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers ./glcts --deqp-case=ES31-CTS.explicit_uniform_location.uniform-loc-implicit-in-some-stages3 Environment: Mesa built with: --enable-debug export MESA_GLES_VERSION_OVERRIDE=3.1 export MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader Reason for fail: Wrong color. Expected green, got (1, 0, 0, 1).
Just making a note here so I don't forget this. I had brief look at 'uniform-loc-implicit-in-some-stages3' some time ago and my impression is that in this test linker overwrites already set correct location because only some of the stages specify location explicitly, I did not start to dig further yet.
I've had a better look and it seems explicit locations are broken since: dcd9cd03837545055ce2a315e7e8840cc3254d1a We've been lucky to not hit this because I guess explicit uniform locations are still rare to be utilized. Will make a Piglit test that exposes this and do some fixes.
With mesa@10b7a7c344 and Iago/Samuels patches from BUG 93321 ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers pass on SKL, but not on BDW and HSW.
(In reply to Marta Löfstedt from comment #3) > With mesa@10b7a7c344 and Iago/Samuels patches from BUG 93321 > > ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers > > pass on SKL, but not on BDW and HSW. Sweet! Today I found that commit dcd9cd03837545055ce2a315e7e8840cc3254d1a is OK after all, it just changes the way how location is read and propagated forward. I'll try to investigate why HSW and BDW fails. It could be still related to the way this commit changes things but not sure.
You will also need: http://patchwork.freedesktop.org/patch/68192/ I thought I had included it in BUG 93321, but I hadn't since it was not needed for those test-cases.
I've sent a fix to: ES31-CTS.explicit_uniform_location.uniform-loc-implicit-in-some-stages3 http://lists.freedesktop.org/archives/mesa-dev/2016-January/104929.html
these 2 should be fixed now by separate patches: ES31-CTS.explicit_uniform_location.uniform-loc-implicit-in-some-stages3 was fixed by commit cf96bce0ca8b2d6b5d4641efea1f2feedc024957 Author: Tapani Pälli <tapani.palli@intel.com> Date: Thu Jan 14 14:10:59 2016 +0200 glsl: mark explicit uniforms as explicit in other stages too If shader declares uniform explicit location in one stage but implicit in another, explicit location should be used. Patch marks implicit uniforms as explicit if they were explicit in previous stage. This makes sure that we don't treat them implicit later when assigning locations. Fixes following CTS test: ES31-CTS.explicit_uniform_location.uniform-loc-implicit-in-some-stages3 v2: move check to cross_validate_globals (Timothy) Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com> --- 8< ----------------------------------------------- ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers was fixed by commit 18c76551ee425b981efefc61f663a7781df17882 Author: Francisco Jerez <currojerez@riseup.net> Date: Sat Jan 2 19:02:09 2016 -0800 i965/gen6-7: Implement stall and flushes required prior to switching pipelines. Switching the current pipeline while it's not completely idle or the read and write caches aren't flushed can lead to corruption. Fixes misrendering of at least the following Khronos CTS test: ES31-CTS.shader_image_load_store.basic-allTargets-store-fs The stall and flushes are no longer required on Gen8+. v2: Emit PIPE_CONTROL with non-zero post-sync op before the write cache flush on SNB due to hardware bug. (Ken) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93323 Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Sorry, Tapani! With: Mesa: git@781d2787bc1 ./glcts --deqp-case=ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers fails on both BDW and SKL.
see: BUG 93725
./glcts --deqp-case=ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers cause GPU_HANG on SKL, with Mesa: git@781d2787bc1 Above, test passed on SKL and BDW with Mesa: git@f4ab7340c
I bisected the SKL regression to: commit 044acb9256046bebec890cac7e42043754459fc2 Author: Francisco Jerez <currojerez@riseup.net> Date: Sat Jan 2 18:35:28 2016 -0800 i965/gen8+: Invalidate color calc state when switching to the GPGPU pipeline.
The regression seems to be another symptom of missing sampler state setup for the compute pipeline, the patch I attached to bug 92589 apparently fixes this too.
I conform that Curros patch from 92589 fix: ES31-CTS.explicit_uniform_location.uniform-loc-types-samplers *** This bug has been marked as a duplicate of bug 92589 ***
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.