[Mesa-dev] gallium scaled types

Christoph Bumiller e0425955 at student.tuwien.ac.at
Mon Sep 12 12:27:36 PDT 2011

On 12.09.2011 21:14, Jose Fonseca wrote:
> ----- Original Message -----
>> 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). 
> Exactly, but not just int-as-float + native integer support + VertexAttribIPointer
> There's also GL 4's double-as-float + native double support + VertexAttribLPointer
>> 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.
> I'd still think an additional state in pipe_vertex_element is by far preferable to the duplication of formats. I'd like us to make a honest attempt at that. Maybe a single flag "as-float" would do it.
> Jose

Well then, I think I've befriended that idea ... let's go glReadPixels
style and add a fetch-as-float bit, but please still rename SCALED to
INT, since a lot of people working on hardware drivers will be used to
the terminology where SCALED implies conversion.

The extra formats would really only make sense for vertices (and allow
for simple use of a to-hw mapping table), but it really does get awkward
with doubles.
Initially I had though that a dvec4 attribute could be implemented as 2
float (i.e. typeless / no conversion) attributes - nv50, nvc0 hardware
has to be configured that way - but from an interface perspective this
is quite ugly.

More information about the mesa-dev mailing list