On Tue, Sep 13, 2011 at 8:45 PM, Jose Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
