System Environment: -------------------------- Libdrm: (master)2.4.22-21-g537703fd4805e9cd352965fce642670986822d22 Mesa: (master)c64447f47de168e82086bc2fb483817b82e59cab Xserver: (master)xorg-server-1.9.99.901-1-g780754050bc9cb1489f92a2a890ab5665e3e6358 Xf86_video_intel: (master)2.13.901-25-g9b967807c2d240488a715509649663aac3583532 Cairo: (master)d3accefd3b9a4db5f07fb1f7bb05fb4238bf36c1 Kernel: (drm-intel-fixes) 1b39d6f37622f1da70aa2cfd38bfff9a52c13e05 CPU: Ironlake core i5 650 OS: Fedora 13(32 bits) Bug detailed description: ------------------------- glReleaseShaderCompiler not implemented yet Reproduce steps: ------------------------- build the attachment and run it.
Created attachment 41361 [details] glGetShaderPrecisionFormat
This should be fixed in master by the following series of commits. Assuming this doesn't cause any regressions, I'll cherry pick these (and some other patches related to GL_ARB_ES2_compatibility) to the 7.10 and 7.9 branches in the next week or so. commit 790ff232e2607a83e6207d06900a5e3de613d161 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 20 12:07:51 2011 -0800 i915: Set correct values for range/precision of fragment shader types commit 3d028024e581b05f71f0be915657c2c105885de6 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 20 12:07:21 2011 -0800 i965: Set correct values for range/precision of fragment shader types commit 04dca296e0a5e5ffbb8acb699e013a23ebd7b645 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 20 12:05:38 2011 -0800 mesa: Set correct values for range/precision of shader integer types commit dde3270c19143b42a55a93e1e85bb24194462671 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 20 12:05:14 2011 -0800 mesa: Connect glGetShaderPrecisionFormat into the dispatch table commit 3ee60a3558a3546b3c3a0a9732d384afcf02994a Author: Brian Paul <brianp@vmware.com> Date: Wed Jan 19 07:41:20 2011 -0700 mesa: implement glGetShaderPrecisionFormat() Drivers should override the default range/precision info as needed. No drivers do this yet.
and... commit 2fb0aebd4a248d2a0725099cd5646253c30c1dc3 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jan 20 13:51:07 2011 -0800 intel: Fix typeos from 3d028024 and 790ff232 ...and remove egg from face.
still failed and running this test case will cause segmentation fault. using dmesg will get following message: glGetShaderPrec[9711]: segfault at 0 ip b7365c0b sp bf9676d0 error 6 in i965_dri.so[b727a000+327000]
(In reply to comment #4) > still failed and running this test case will cause segmentation fault. > using dmesg will get following message: > glGetShaderPrec[9711]: segfault at 0 ip b7365c0b sp bf9676d0 error 6 in > i965_dri.so[b727a000+327000] That's because your test is broken. It's passing uninitialized pointers to glGetShaderPrecisionFormat.
Created attachment 42503 [details] fix a bug for the test case of glGetShaderPrecisionFormat
Oh sorry. I have fixed the bug of the test case and it passes whih following commit Libdrm: (master)2.4.23-6-g550fe2ca3b29ad2191eab4fdfbed9ed21e25492d Mesa: (master)2db46fe5f0145a6afff5b8edc2f00b8c734bb640 Xserver: (master)xorg-server-1.9.99.901-165-gbe3be7580b6f6fd2f7fa4d4abfe5e1ab19470223 Xf86_video_intel: (master)2.14.0-12-g5baa63c634990810a66c3150b4f2b76fcee2df38 Cairo: (master)ff9e962165905f9b3477e125de227c69aebf9510 Kernel: (drm-intel-next) fe4402931e43e81a4129eba41d05cf8907603af5
The test is still incorrect. The range parameter returns two values, not one. So you need something like GLint range[2], precision; glGetShaderPrecisionFormat(GL_VERTEX_SHADER, GL_HIGH_FLOAT, range, &precision); Also, it would be nice if the test would query all the supported shader types and precision types to make sure no errors are generated and the results are sensical.
(In reply to comment #8) > The test is still incorrect. The range parameter returns two values, not one. > > So you need something like > GLint range[2], precision; > > glGetShaderPrecisionFormat(GL_VERTEX_SHADER, GL_HIGH_FLOAT, range, &precision); > > Also, it would be nice if the test would query all the supported shader types > and precision types to make sure no errors are generated and the results are > sensical. I already added that test to piglit. It's arb_es2_compatibility-getshaderprecisionformat. It checks all of the shader types and precision types and verifies that the minimum values required by the spec are returned. We should be able to build real ES2 tests in piglit within a week or so. Once that happens, all of the tests in tests/spec/arb_es2_compatibility will get "ported" to ES2. The only change that will need to happen is removing the assumption that highp is supported for fragment shaders.
Created attachment 42624 [details] use the new attachment to check glGetShaderPrecisionFormat
(In reply to comment #10) > Created an attachment (id=42624) [details] > use the new attachment to check glGetShaderPrecisionFormat This test looks correct. Does it pass on master? I plan to cherry pick some of these patches back to 7.9 and 7.10. In the presence of the test I mentioned in comment #9, this new test is not useful.
Yes the new test case just can check glGetShaderPrecisionFormat and it passes on master. Following is the verified commit. Libdrm: (master)2.4.23-6-g550fe2ca3b29ad2191eab4fdfbed9ed21e25492d Mesa: (master)2db46fe5f0145a6afff5b8edc2f00b8c734bb640 Xserver: (master)xorg-server-1.9.99.901-165-gbe3be7580b6f6fd2f7fa4d4abfe5e1ab19470223 Xf86_video_intel: (master)2.14.0-12-g5baa63c634990810a66c3150b4f2b76fcee2df38 Cairo: (master)ff9e962165905f9b3477e125de227c69aebf9510 Kernel: (drm-intel-next) fe4402931e43e81a4129eba41d05cf8907603af5
Closing since, from the comments, it sure sounds fixed.
(In reply to comment #13) > Closing since, from the comments, it sure sounds fixed. But it hasn't been cherry picked back to 7.10 or 7.9.
Fixed in 7.9 (4d2a725196e70f5480a90d9af818a1b508ac98a9) and 7.10 (f9e01af6c3071669c2d52ddaeea98c98b8b7e10c).
verified with (7.9)2b41289691421863970c73745ad6e191da4b32d7 and (7.10)f9f01e40c7ca66b72ad6c8fe98eaedbc03ae59b8
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.