[Mesa-dev] gallium scaled types

[Marek Olšák]

On Tue, Sep 13, 2011 at 8:45 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>
>
> ----- 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.

We have already been using is_format_supported for vertex buffers
since ARB_half_float_vertex.

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

You are talking about apples and oranges. If
PIPE_FORMAT_R10G10B10A2_SSCALED is redundant with
PIPE_FORMAT_R10G10B10A2_SINT, then also PIPE_FORMAT_R10G10B10A2_SNORM
is redundant with PIPE_FORMAT_R10G10B10A2_SINT. If we shouldn't have a
set of types for convert-to-float-unnormalized, then obviously we
shouldn't have a set of types for convert-to-float-normalized either.

We need a state variable somewhere that can take these 3 values:
- NORM
- SCALED
- INT
And not having one half of the type encoded in a pipe format, and
another half encoded in some CSO.

As a side note, I was halfway through renaming PIPE_FORMAT_*SCALED to
PIPE_FORMAT_*INT, but decided to discard that work, because it would
be a big fat lie. Every piece of code assumes the type is SCALED and
nothing assumes it's INT.

Marek