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.sepshaderobjs.StateInteraction Environment: Mesa built with: --enable-debug export MESA_GLES_VERSION_OVERRIDE=3.1 export MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader ----------------- Reason for fail: es31cSeparateShaderObjsTests.cpp:2478
I'm listing here commits that were done to fix issues with this: 2377db2c4e87ad7d418f1f3218b501c1a0cd8373 8cc372b6d910c4d3b59066cbb47434da0d765196 Also, there are 2 more patches on mesa-dev list that will take this test further, review help appreciated :) http://lists.freedesktop.org/archives/mesa-dev/2015-December/102663.html http://lists.freedesktop.org/archives/mesa-dev/2015-December/102724.html
it looks like fixing bug 93320 will fix rendering output of the matching tests, adding dependency
commit 11fc7ad62ef9aa4c9df71e4e001582f8017e7a81 Author: Timothy Arceri <timothy.arceri@collabora.com> Date: Wed Jan 6 12:40:12 2016 +1100 mesa: remove link validation that should be done elsewhere Even if re-linking fails rendering shouldn't fail as the previous succesfully linked program will still be available. It also shouldn't be possible to have an unlinked program as part of the current rendering state. This fixes a subtest in: ES31-CTS.sepshaderobjs.StateInteraction This change should improve performance on CPU limited benchmarks as noted in commit d6c6b186cf308f. >From Section 7.3 (Program Objects) of the OpenGL 4.5 spec: "If a program object that is active for any shader stage is re-linked unsuccessfully, the link status will be set to FALSE, but any existing executables and associated state will remain part of the current rendering state until a subsequent call to UseProgram, UseProgramStages, or BindProgramPipeline removes them from use. If such a program is attached to any program pipeline object, the existing executables and associated state will remain part of the program pipeline object until a subsequent call to UseProgramStages removes them from use. An unsuccessfully linked program may not be made part of the current rendering state by UseProgram or added to program pipeline objects by UseProgramStages until it is successfully re-linked." "void UseProgram(uint program); ... An INVALID_OPERATION error is generated if program has not been linked, or was last linked unsuccessfully. The current rendering state is not modified." V2: apply the rule to both core and compat. Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@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.