[Mesa-dev] gallium scaled types

Christoph Bumiller e0425955 at student.tuwien.ac.at
Mon Sep 12 10:05:13 PDT 2011

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

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.

> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list