[Mesa-dev] gallium scaled types

[Jose Fonseca]

----- Original Message -----
> On Mon, Sep 12, 2011 at 8:51 PM, Jose Fonseca <jfonseca at vmware.com>
> wrote:
> >
> > This is what the OpenGL spec says about VertexAttribIPointer:
> >
> >  Data for an array specified by VertexAttribPointer will
> >  be converted to floating-point by normalizing if normalized is
> >  TRUE, and converted
> >  directly to floating-point otherwise. Data for an array specified
> >  by VertexAttribI-
> >  Pointer will always be left as integer values; such data are
> >  referred to as pure
> >  integers.
> >
> > Formats describe how to interpret the data in memory, and
> > normalization is an important part of that interpretation. But
> > this "integer" vs "pure integer" distinction merely describes the
> > recipient of that interpretation , and not the source
> > interpretation itself.  In this is merely to ensure no precision
> > loss, although a recipient that can hold the data without loss
> > could be determined without any assistance.
> >
> > AFAICS, saying that the integers should be kept as integers only
> > makes sense in the context of shaders, and nothing else. A blit
> > from a integer texture to a pure integer texture is nothing but a
> > memcpy.
> 
> First and foremost, SCALED has never been used as a pure integer type
> in Gallium in the same manner NORM is not a pure integer type. It is
> what it is: SCALED, that is non-normalized. Maybe it was meant to be
> an integer, but it's not and it's not equivalent to any of the D3D10
> integer types *now*. The D3D10 integer types don't exist in Gallium.
> Please see also below.
> 
> 
> > Gallium has formats named as PIPE_xxx_xSCALED for historical
> > reasons, but PIPE_xxx_xINT would be better.  They describe
> > integers in memory.
> 
> NORM are also integers in memory, yet they are not perceived as
> integers by shaders. Yes, the INT is the basic type. But, ints can be
> read either as:
> 1) converted to float normalized (NORM)
> 2) converted to float non-normalized (SCALED)
> 3) no conversion (just INT)

I did a better job explaining why I consider the post-conversion to float different from normalization in another reply.  In short it affects the interpretation of the bits (same as 16.16 fixed point vs 32 unorm vs 32 uint does).

Note also that things get even more murky with doubles. Along the same lines, a double can be read as:
1) converted to float (what name should this be? "DOWNCASTED"?)
2) no conversion (just DOUBLE)

If we go this route, there is no tell where it will stop (it's easy to imagine 64bits ints in the future, who knows what else).  In the extreme, any of the N formats we have currently can be converted to M shader types, yielding N*M potential types.
 
> > Note that D3D10 has no concept of PIPE_xxx_xSCALED vs PIPE_xxx_xINT
> > formats either [1].
> 
> That's because D3D10 doesn't have scaled types at all, so they are
> not
> listed there. There is no concept or convention involved. But the
> scaled types *do* exist in OpenGL and they *do* exist in hardware. As
> I said earlier, scaled and int are completely different types in
> R600,
> despite the fact they are all ints in memory, so are the normalized
> ones.

D3D10 deliberately chose not to have the explicit scaled types, but it can support the same vertex data just as well. From the same MSDN page:

  Direct3D 9 Format	Direct3D 10 Format
  D3DDECLTYPE_SHORT4	DXGI_FORMAT_R16G16B16A16_SINT Note: Shader gets SINT values, but if Direct3D 9 style integral floats are needed, SINT can just be converted to float32 in shader.

It's really just a matter of who does the conversion.

But I understand you and Christopher 's point: hardware has support to do (or not do) the conversion outside the shader. And I think it's worth exposing that ability through Gallium, for benefit of legacy apps. I just think it's not worth to tax the pipe_format state so much, just to provide this extra bit of expressiveness.

> Adding an is-scaled flag to pipe_vertex_element_state would do the
> job though.

Great. Let's give it shot, and see if there are any pain points. It looks less invasive too, so hopefully it is easy to try.

Jose