Bug 90748

Summary: [BDW Bisected]dEQP-GLES3.functional.fbo.completeness.renderable.texture.depth.rg_half_float_oes fails
Product: Mesa Reporter: lu hua <huax.lu>
Component: Drivers/DRI/i965Assignee: Tapani Pälli <lemody>
Status: CLOSED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: high CC: kevin.rogovin, kondapallykalyancontribute, lemody
Version: git   
Hardware: All   
OS: Linux (All)   
i915 platform: i915 features:
Attachments: patch #1
patch #2
patch #3
patch #1 v2
fix for the failing deqp cases

Description lu hua 2015-05-29 07:37:05 UTC
System Environment:
Platform: BDW
Libdrm:		(master)libdrm-2.4.61-4-gfde4969176822fe54197b6baa78f8b0ef900baba
Mesa:		(master)10aacf5ae8f3e90e2f0967fbdcf96df93e346e20
Xserver:	(master)xorg-server-1.17.0-157-gcbb7eb73b5399e31a7afb800363504d539df0ecf
Libva:		(master)4763db1c2133d4e6b92355938ecb6f23a7767b6b
Kernel:   (drm-intel-nightly)f9d865e87168eaba908020942f458c40facd6060

Bug detailed description:
It fails on BDW with Mesa master branch.
good commit: 2c2a92d5b87f669da9fa88fdd094304fcf1eb09a
bad commit: e638841b87a5d9454739195b49c403ca9a22a59e

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


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"
Comment 1 shuo.wang 2015-05-29 07:42:37 UTC
This commit(e638841b87a5d9454739195b49c403ca9a22a59e) will also cause below cases fail:
Comment 2 lu hua 2015-05-29 07:49:21 UTC
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>
Comment 3 Tapani Pälli 2015-06-03 07:12:38 UTC
Created attachment 116256 [details] [review]
patch #1
Comment 4 Tapani Pälli 2015-06-03 07:12:53 UTC
Created attachment 116257 [details] [review]
patch #2
Comment 5 Tapani Pälli 2015-06-03 07:13:05 UTC
Created attachment 116258 [details] [review]
patch #3
Comment 6 Tapani Pälli 2015-06-03 07:31:15 UTC
FYI attached patches fix the deqp tests, unfortunately conformance tests for half float start to fail
Comment 7 Tapani Pälli 2015-06-03 08:37:32 UTC
Created attachment 116259 [details] [review]
patch #1 v2
Comment 8 Tapani Pälli 2015-06-03 09:19:18 UTC
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?
Comment 9 Tapani Pälli 2015-06-03 10:53:46 UTC
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:


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?
Comment 10 kalyank 2015-06-03 17:46:19 UTC
Thats my observation too. Spec doesn't mention combination of RED,RG  with unsized formats as valid

Comment 11 Kaveh 2015-06-04 21:34:57 UTC
Ian, can you please confirm that this is only due to a spec issue?
Comment 12 Gavin Hindman 2015-06-06 01:24:29 UTC
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.
Comment 13 Matt Turner 2015-06-06 06:45:05 UTC
(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.
Comment 14 Tapani Pälli 2015-06-08 05:11:07 UTC
(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

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.
Comment 15 Tapani Pälli 2015-06-08 05:40:23 UTC
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).
Comment 16 Tapani Pälli 2015-06-08 06:03:56 UTC
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.


I will try to dig in to the failing conformance test and see what it expects.
Comment 17 Tapani Pälli 2015-06-08 08:15:24 UTC
I've sent 2 patches to mesa-dev that fix this without any regressions, waiting for review feedback.
Comment 18 kalyank 2015-06-08 17:39:35 UTC
Hmm, didn't realize we had EXT_texture_rg
Seems, like someone already encountered similar issue earlier here:
Comment 19 Tapani Pälli 2015-06-09 06:54:15 UTC
ok, now I've sent v2 of both patches, these are a lot simpler and pass all conformance + deqp tests
Comment 20 Gavin Hindman 2015-06-09 17:50:48 UTC
Have these patches merged?
Comment 21 kalyank 2015-06-09 18:46:26 UTC
The patches are not merged yet. The patches just got reviewed by Kenneth Graunke.
Comment 22 Tapani Pälli 2015-06-10 10:05:34 UTC
fixes pushed to master
Comment 23 shuo.wang 2015-06-15 03:00:42 UTC
Verified and fixed by Mesa ff9653775962ab661c4891721b1b93d077d1f2db and kernel 4.1.0-rc7_drm-intel-nightly_4643c5_20150613+.

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.