[Mesa-dev] [RFC PATCH] Add support for ARB_vertex_type_2_10_10_10_rev on i965
kenneth at whitecape.org
Sun Oct 14 00:52:00 PDT 2012
On 10/13/2012 07:13 PM, Kenneth Graunke wrote:
> On 10/09/2012 01:06 PM, Kenneth Graunke wrote:
>> On 10/09/2012 02:33 AM, Chris Forbes wrote:
>>> This series almost adds support for ARB_vertex_type_2_10_10_10_rev on
>>> Working from the Sandybridge and Ivybridge PRMs, this ought to work
>>> (what look
>>> like the correct dwords end up in the batch, etc).
>>> Details pieced together from both PRMs, since the Sandybridge PRM
>>> surface format encodings which aren't in its master table, and the
>>> PRM is missing the data on which formats are usable in vertex buffers.
>>> Any hints on what I'm missing -- and trying it on an Ivybridge
>>> machine, where
>>> the formats *definitely* ought to all exist -- would be appreciated.
>> Hi Chris,
>> I looked over your patches this morning and at first glance, they look
>> good! Unfortunately, I ran the piglit tests and got failures. Not
>> entirely sure what's going on there. Endianness issues perhaps?
>> I'll try and take a more detailed look later this week.
>> Thanks so much for doing this!
> Unfortunately, it's looking like the 10_10_10_2 USCALED/SSCALED formats
> don't work in hardware, at least on Ivybridge...the vertices get
> converted to floats incorrectly. Apparently the workaround is to pass
> them in as UINT and emit shader code to fix it up (similar to how we do
> for GL_FIXED). I'll try and investigate more and send patches...
Scratch one mystery:
If you look in the Sandybridge PRMs, volume 4 part 1, page 90 and
following, you'll see that not all of the 10-10-10-2 formats have a "Y"
in the "Input Vertex Buffer" column.
The ones that are supported are:
(and AFAICT these should be supported all the way back to Gen4)
Unfortunately, the Ivybridge docs appear to have lost the information
about what's unsupported. Looking at the internal docs[*], it appears
the following formats are *not* supported for vertex buffer data on
This explains why I saw a lot of test failures with your patches:
they're trying to use formats which aren't supported.
So it does seem to be necessary to use either R10G10B10A2_UINT or
R10G10B10_SNORM_A2_UNORM and emit shader code to convert the data.
I apologize for the documentation...this really wasn't clear at all.
[*] For Intel folks reading along, this is based on the table in
vol2a.02 / Vertex Fetch (VF) Stage / 3D Primitive Processing /
More information about the mesa-dev