[Mesa-dev] gallium scaled types

[Jose Fonseca]

----- Original Message -----
> José, Roland,
> 
> there is a problem with the proposed approach of having the
> convert_to_float flag. That flag might not be supported for certain
> integer formats. We would need to update some more places, e.g.
> is_format_supported:
> 
> boolean (*is_format_supported)( struct pipe_screen *,
>                                    enum pipe_format format,
>                                    enum pipe_texture_target target,
>                                    unsigned sample_count,
>                                    unsigned bindings,
>                                    boolean can_be_converted_to_float
>                                    );



> See the last parameter. Ugly, isn't it? There is no other way around
> it. 

AFAIK, is_format_supported() was never used for vertex formats, just textures. And given that textures can only be sampled without implicit conversion (i.e., the "pure" vs scaled integers doesn't apply), I see no need to add can_be_converted_to_float to is_format_supported().

I think what we need a is_vertex_format_supported(), or something like that.

> The translate module also needs to distinguish between scaled and
> integer types. Translate currently doesn't support integers, only
> scaled. The code in Translate would either have to look like this:
> 
> case PIPE_FORMAT_R32_SSCALED:
>    return is_int ? &emit_R32_SINT : &emit_32_SSCALED;
> 
> Or like this:
> 
> case PIPE_FORMAT_R32_SINT:
>    return is_scaled ? &emit_R32_SSCALED : &emit_32_SINT;

No, the translate module doesn't need to change like that.

What the translate module needs to do is ensure that PIPE_FORMAT_xxxx_SINT -> PIPE_FORMAT_xxx_SINT doesn't get converted to a float intermediate, but into an integer intermediate instead.

When the translate module is converting from PIPE_FORMAT_xxx_SINT -> PIPE_FORMAT_xxx_FLOAT or PIPE_FORMAT_xxx_FLOAT -> PIPE_FORMAT_xxx_SINT, telling that you want "pure integers" is pointless!

So, yes, the translate module's _internals_ needs to change, but its interface needs _no_ change at all. In summary, the "is_int" flag you mention can be determined from the current inputs.

> The fairly new extension GL_ARB_vertex_type_2_10_10_10_rev also adds
> new scaled types and NOT integers (see Issue 7 of the specification).

It looks you need ta PIPE_FORMAT_R10G10B10A2_SNORM and a PIPE_FORMAT_R10G10B10A2_SINT (previously known as _SCALED) to acommodate the different semantics for different legacy attributes.

But as far as the "pure integer" issue, it is in no aspect different from any other format.


Jose