Bug 90748

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