José, I understand what you are trying to tell me, but it's not good enough to convince me. I am mainly advocating what maps nicely to my hardware and what appears to be a sane long-term solution in my opinion. The Translate example might not be relevant, because it doesn't work how hardware does.
To me, the pipe_format defines how a value in memory is stored in a shader register. There is no fetch-as-float or fetch-as-int function. There is just fetch(), and the pipe_format defines how the fetch function looks like, including type conversions. The fact we'd need a can-be-converted-to-float flag in the is_format_supported query just proves my point that it's an essential property of pipe_format, so essential that it can completely change the outcome of the query. IMO, the only two good arguments for not adding new formats have been: - It would be less work. (can't argue with that) - Let's not pollute pipe formats with formats that are only used by a vertex fetcher. (heh, good one! but then you can no longer claim that vertex and texture formats are unified) The Radeon drivers don't really have any switch(pipe_format) statements for vertices and textures. They just generate something like a "hardware fetch description" directly from util_format_description. The is_format_supported query is implemented in the exact same way - we just examine whether the hardware can do what util_format_description describes. There is no table of supported formats. You can easily see why I'd like to have the pure ints somehow expressed through util_format_description. We still have switch(pipe_format) statements for colorbuffers though. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
