System Environment: -------------------------- Platform: BDW Libdrm: (master)libdrm-2.4.61-4-gfde4969176822fe54197b6baa78f8b0ef900baba Mesa: (master)10aacf5ae8f3e90e2f0967fbdcf96df93e346e20 Xserver: (master)xorg-server-1.17.0-157-gcbb7eb73b5399e31a7afb800363504d539df0ecf Xf86_video_intel:(master)2.99.917-313-gfb1643f0f904eb258da71cd0b8deb8d3ec6dafed Libva: (master)4763db1c2133d4e6b92355938ecb6f23a7767b6b Libva_intel_driver:(master)4a1c4d21f3428b08ef765d7f7de75b97006514ac Kernel: (drm-intel-nightly)f9d865e87168eaba908020942f458c40facd6060 Bug detailed description: ----------------------------- It fails on BDW with Mesa master branch. good commit: 2c2a92d5b87f669da9fa88fdd094304fcf1eb09a bad commit: e638841b87a5d9454739195b49c403ca9a22a59e output: dEQP Core 2014.x (0xcafebabe) starting.. target implementation = 'X11 EGL/GLX' Test case 'dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.rg_half_float_oes'.. Fail (Framebuffer checked as incomplete, but with wrong status) Test case duration in microseconds = 4701 us DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%) Reproduce steps: ---------------------------- 1. xinit 2. ./deqp-gles3 --deqp-gl-context-type=egl --deqp-case="dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.rg_half_float_oes"
This commit(e638841b87a5d9454739195b49c403ca9a22a59e) will also cause below cases fail: dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.red_half_float_oes dEQP-GLES3.functional.fbo.completeness.renderable.texture.stencil.rg_half_float_oes dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.red_float dEQP-GLES3.functional.fbo.completeness.renderable.texture.stencil.red_float dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rg_half_float_oes dEQP-GLES3.functional.fbo.completeness.renderable.texture.stencil.rg_float dEQP-GLES3.functional.fbo.completeness.renderable.texture.stencil.red_half_float_oes dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.rg_float dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rg_float dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.red_half_float_oes dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.red_float
Bisect shows: e638841b87a5d9454739195b49c403ca9a22a59e is the first bad commit. commit e638841b87a5d9454739195b49c403ca9a22a59e Author: Kalyan Kondapally <kondapallykalyancontribute@gmail.com> AuthorDate: Wed Jan 7 20:30:27 2015 -0800 Commit: Tapani Pälli <tapani.palli@intel.com> CommitDate: Thu Jan 29 08:22:12 2015 +0200 Mesa: Advertise GL_OES_texture_*float* extensions support with i965. This patch advertises support for GL_OES_texture_*float* extensions when using i965 drivers. Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com> Signed-off-by: Kalyan Kondapally <kalyan.kondapally@intel.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Created attachment 116256 [details] [review] patch #1
Created attachment 116257 [details] [review] patch #2
Created attachment 116258 [details] [review] patch #3
FYI attached patches fix the deqp tests, unfortunately conformance tests for half float start to fail
Created attachment 116259 [details] [review] patch #1 v2
Created attachment 116261 [details] [review] fix for the failing deqp cases Here's a fix for all cases, unfortunately this makes still conformance for ES 3.0 fail, will need to investigate why this is. Originally the intention of OES_texture_float work was to have it for ES2 but unfortunately much of the code is common with ES3, will need to check if we could make OES_texture_float exposed for ES2 context only?
The more I look at this the more fishy this seems. I find it very hard to extract from ES 3.0 spec that what are valid combinations for glTexImage call. However according to following man page: https://www.khronos.org/opengles/sdk/docs/man3/html/glTexImage2D.xhtml it does not seem that GL_RED and GL_RG can be used with unsized internal formats like deqp does, according to man page it is required to be a sized format like GL_RG32F so the checks in _mesa_es3_error_check_format_and_type seem quite correct. So, after all the patches enabling this I actually have a feeling I should not and this is a bug in the tests. Could someone else verify if he has same understanding of the spec according to the format requirements?
Thats my observation too. Spec doesn't mention combination of RED,RG with unsized formats as valid https://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.2.pdf
Ian, can you please confirm that this is only due to a spec issue?
If this is an issue in the test, then why would it have previously been passing, but now is not? These are regressions against a Mesa snapshot that's only a few months old, not standing historical failures.
(In reply to Gavin Hindman from comment #12) > If this is an issue in the test, then why would it have previously been > passing, but now is not? These are regressions against a Mesa snapshot > that's only a few months old, not standing historical failures. It's because the test was not running before we enabled the extension.
(In reply to Matt Turner from comment #13) > (In reply to Gavin Hindman from comment #12) > > If this is an issue in the test, then why would it have previously been > > passing, but now is not? These are regressions against a Mesa snapshot > > that's only a few months old, not standing historical failures. > > It's because the test was not running before we enabled the extension. Yeah, these subtests are only run with the new enabled functionality. Unfortunately the main test also covers other formats, so enabling floating point textures makes the whole test fail while it used to pass earlier. We are still passing all the other subtests (and all the floating point format tests expect when using GL_RED and GL_RG). There are 2 khronos bugs lingering around this issue: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7333 (still open) https://cvs.khronos.org/bugzilla/show_bug.cgi?id=8909 (resolved in gles 3.0) Reading these it's still a bit unclear to me how this should be resolved. OpenGL ES 3.0 clearly states (in 4.4.4 Framebuffer completeness): "The following base internal formats from table 3.15 are color-renderable: ALPHA , RED , RG , RGB , and RGBA . The sized internal formats from ta- ble 3.16 that have a color-renderable base internal format are also color- renderable. No other formats, including compressed internal formats, are color-renderable." However, GL_RED or GL_RG are not valid for OpenGL ES 2.0 and not enabled by the extension. I think this is part of bug #7333, it is not clear what sized format should we pick internally when RED or RG is given by the user.
Even the test source code says (see glsFboCompletenessTests.cpp when adding GL_RG and GL_RED): "These are not specified to be color-renderable, but the wording is exactly as ambiguous as the wording in the ES2 spec." I find this comment worrying since it is not clear if we should enable these formats, (especially when conformance tests then start to fail).
Having said all that, the support is required by the test because of the combination of EXT_texture_rg, OES_texture_float and OES_texture_half_float. https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_rg.txt I will try to dig in to the failing conformance test and see what it expects.
I've sent 2 patches to mesa-dev that fix this without any regressions, waiting for review feedback.
Hmm, didn't realize we had EXT_texture_rg Seems, like someone already encountered similar issue earlier here: http://lists.freedesktop.org/archives/mesa-users/2014-January/000745.html
ok, now I've sent v2 of both patches, these are a lot simpler and pass all conformance + deqp tests
Have these patches merged?
The patches are not merged yet. The patches just got reviewed by Kenneth Graunke.
fixes pushed to master
Verified and fixed by Mesa ff9653775962ab661c4891721b1b93d077d1f2db and kernel 4.1.0-rc7_drm-intel-nightly_4643c5_20150613+. Thanks
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.