[Mesa-dev] gallium scaled types

[Roland Scheidegger]

Am 12.09.2011 19:05, schrieb Christoph Bumiller:
> On 12.09.2011 18:41, Jose Fonseca wrote:
>> 
>> ----- Original Message -----
>>> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger 
>>> <sroland at vmware.com> wrote:
>>>> Am 11.09.2011 19:17, schrieb Dave Airlie:
>>>>> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
>>>>> <airlied at gmail.com> wrote:
>>>>>> Hi guys,
>>>>>> 
>>>>>> not really finding a great explaination in my 2 minute
>>>>>> search, of what the USCALED and SSCALED types are
>>>>>> representative of
>>>>>> 
>>>>>> On r600 hw at least we have a SCALED type, which seems to
>>>>>> be an integer in float point format, as well as an INT type
>>>>>> which is natural integers.
>>>>> Talked on irc with calim and mareko, makes sense now, need to
>>>>> add UINT/SINT types will document things maybe a bit more on
>>>>> my way past.
>>>>> 
>>>>> will also rename the stencil types.
>>>> 
>>>> Hmm what's wrong with them? USCALED is a unsigned int type
>>>> which in contrast to UNORM isn't normalized but "scaled" to the
>>>> actual value (so same as UINT really). Same for SSCALED which
>>>> is just signed instead of unsigned. And the stencil types seem
>>>> to fit already.
>>> No, they are not.
>>> 
>>> SCALED is an int that is automatically converted to float when 
>>> fetched by a shader.
>>> 
>>> The SCALED types are OpenGL's non-normalized *float* vertex
>>> formats that are stored in memory as ints, e.g.
>>> glVertexAttribPointer(... GL_INT ...). There are no SCALED
>>> textures or renderbuffers supported by any hardware or exposed by
>>> any API known to me. Radeons seem to be able to do SCALED types
>>> according to the ISA docs, but in practice it only works with
>>> vertex formats and only with SCALED8 and SCALED16 (AFAIK).
>>> 
>>> Then there should be the standard INT types that are not
>>> converted to float upon shader reads. Those can be specified as
>>> vertices by glVertexAttribIPointer(... GL_INT ...) (note the
>>> *I*), or as integer textures. This is really missing in Gallium.
>> Pipe formats describe how the data should be interpreted.
>> 
>> IMO, the type of register they will be stored after interpretation
>> is beyond the the scope of pipe_format.  I think that is purely in
>> the realm of shaders.
>> 
>> For example, when doing texture sampling, if
>> PIPE_R32G32B32A32_SSCALED should be read into a integer register or
>> float registers should be decided by the texture sample opcode.
>> Not the pipe_format.
>> 
>> And in the case of vertex shaders inputs, the desired register type
>> (float, int, double) should be not in pipe_vertex_element at all,
>> but probably in the shader input declaration. Given that it ties
>> more closely with shader itself: an integer vertex input will be
>> used usually with integer opcodes, and vice-versa. Independent of
>> the actually vertices being stored in the vertex buffer as integers
>> or not.
> 
> No. If you declare a shader input as float and you use 
> VertexAttribIPointer, you do NOT get a float, even if the shader
> expects it.
> 
> The vertex format describes a property of the vertex fetch stage
> (input assembler) and determines how data is brought from a vertex
> buffer into vertex attribute memory / cache; what the shader does
> with the data is completely unrelated.

Ah I see the problem now. This boils down to the implicit
convert-to-float which earlier GL (and hw) did, but you most likely
don't want (well the non-normalizing case) if you support native
integers (but you still need to be able to do it for GL). I think the
non-normalized ints-as-floats is something d3d10 ditched.
I'm not really too thrilled seeing more formats which are essentially
the same (as the values don't actually change it's just float vs. int
type) but it seems GL actually wants this and hw can actually do it, so
I don't really see a better solution. I guess it would be possible to
make the int-as-float bit part of the pipe_vertex_buffer or something
instead but I'm not sure it would work nicely.

Roland