[Mesa-dev] gallium scaled types

[Jose Fonseca]

----- 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.

Otherwise we might as well just start naming the formats as PIPE_foo_INT_WHATEVER, PIPE_foo_INT_I_REALLY_MEANT_IT_NOW, PIPE_foo_DOUBLE_BUT_NOT_QUITE, and PIPE_foo_DOUBLE_DONT_YOU_DARE_DOWNCAST_TO_FLOAT_OR_THE_BOOGIE_MAN_WILL_GET_YOU! :DDD

Jose