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. 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.
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).
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?
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
