Bug 110305 - Iris driver fails ext_packed_depth_stencil-getteximage test
Summary: Iris driver fails ext_packed_depth_stencil-getteximage test
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/Iris (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-02 08:59 UTC by asimiklit
Modified: 2019-04-23 10:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description asimiklit 2019-04-02 08:59:12 UTC
It fails on a FLOAT_32_UNSIGNED_INT_24_8_REV format
Stencil values which were recorded by a glTexImage2D are not
equal to the stencil values which were received by a glGetTexImage
https://gitlab.freedesktop.org/mesa/piglit/blob/master/tests/spec/ext_packed_depth_stencil/getteximage.c#L131

The result examples for a 8-bit stencil:
i965:
+--------------------+-----------+
|Expected pixel value|Pixel value|
+--------------------+-----------+
|     0x000000a3     | 0x000000a3|
|     0x000000a2     | 0x000000a2|
|     0x000000a1     | 0x000000a1|
|     0x000000a0     | 0x000000a0|
|     0x0000009f     | 0x0000009f|
|     0x0000009e     | 0x0000009e|
+--------------------+-----------+

iris:
+--------------------+-----------+
|Expected pixel value|Pixel value|
+--------------------+-----------+
|     0x000000a3     | 0x000055a3|
|     0x000000a2     | 0x000055a2|
|     0x000000a1     | 0x000000a1|
|     0x000000a0     | 0x000000a0|
|     0x0000009f     | 0x3ec2c29f|
|     0x0000009e     | 0x3ec6c69e|
+--------------------+-----------+

Note: gallium doesn't clean an unused space here (but I guess that it is an expected behavior):
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/auxiliary/util/u_transfer_helper.c#L276-301

Actually I guess that it is rather a piglit test issue because spec saying
about FLOAT_32_UNSIGNED_INT_24_8_REV the following:

+---------------+------------+---+
| 1st component |   Unused   |2nd|
+---------------+------------+---+
     32-bit        24-bit     8-bit

I actually guess that "unused" means that there is no guarantee that it
must be clean but I am not sure whether it enough for mesa or I should find
some more strict wording about it.

So possible piglit test fix is:
   -if (buf[i*2+1] != tex[i*2+1]) {
   +if ((buf[i*2+1] & 0xffu) != tex[i*2+1]) {
Comment 1 asimiklit 2019-04-03 13:12:18 UTC
I created an MR for this issue:
https://gitlab.freedesktop.org/mesa/piglit/merge_requests/32

And some clarification question on Khronos gitlab:
https://github.com/KhronosGroup/OpenGL-API/issues/48

I will create a MR for mesa/gallium as was suggested by Eric Anholt <eric@anholt.net>
Comment 2 asimiklit 2019-04-23 10:12:21 UTC
Fixed by a commit: cade9001b1758ee9b76f365b02822c97a414006a

This is a field of FLOAT_32_UNSIGNED_INT_24_8_REV texture pixel.
OpenGL spec "8.4.4.2 Special Interpretations" is saying:
   "the second word contains a packed 24-bit unused field,
    followed by an 8-bit index"
The spec doesn't require us to clear this unused field
however it make sense to do it to avoid some
undefined behavior in some apps.


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.