[Mesa-dev] gallium scaled types

Roland Scheidegger sroland at vmware.com
Tue Sep 13 11:44:11 PDT 2011


Am 13.09.2011 19:32, schrieb Marek Olšák:
> 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 );
I agree this is ugly.
Almost makes me wish all formats were typeless with a separate
FLOAT/UNORM/SNORM/USCALED/SSCALED/UINT/SINT specifier (but we had
something like that in the past and it certainly wasn't ideal neither).

> 
> See the last parameter. Ugly, isn't it? There is no other way around
> it. 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;
> 
> Such SCALED vs INT conditionals would be everywhere, including all the drivers.
Well everywhere for vertex fetch in all drivers.
For most hw drivers I think though it wouldn't nearly be that bad, quite
the contrary you save half the case statements and probably only need to
check that is_scaled flag once for all formats to set some bit somewhere.

> 
> 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).
Yes, but these could be handled just the same as well (e.g. as SINT with
convert_to_float set).


> 
> The only clean way is to add new pipe formats with suffixes UINT and
> SINT. The only duplication would be in u_format, which does
> int<->float conversions for pretty much every pipe format. Everywhere
> else, there would be no duplication whatsoever, same as there is no
> duplication with NORM vs SCALED.
> 
> So what do you think? Do we want a can_be_converted_to_float parameter
> in is_format_supported and conditionals is_int? and is_scaled?
> everywhere in this project?
> Or do we actually want clean SINT and UINT pipe formats?

You make it sound like these conditionals need to be in a lot of places,
I don't think it would be quite that bad. Still, there seems to be merit
to the argument saying that it would be cleaner to just add more
formats, after all we've got a lot of "interpretation" bits in there
anyway. I dunno.

Roland




More information about the mesa-dev mailing list