[Mesa-dev] gallium scaled types
jfonseca at vmware.com
Tue Sep 13 12:07:23 PDT 2011
----- Original Message -----
> > 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
> 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.
Just to be clear, the translate module caller should tell, for every vertex input format, how it wants its output format to be. Typically either
Note that when input vertices are integers, saying that it wants scaled "non-pure" integers is the same as saying it way floats.
input format output format description
R32G32B32A32_FLOAT | R32G32B32A32_FLOAT | float
R32G32B32A32_INT | R32G32B32A32_FLOAT | scaled, aka as not "pure integer"
R32G32B32A32_INT | R32G32B32A32_INT | unscaled, aka "pure integer"
This is actually another good reason why having the pure vs non-pure integers distinction in the pipe format enum adds redundant or conflicting info...
More information about the mesa-dev