On Fri, Sep 16, 2011 at 5:40 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> ----- Original Message -----
>> 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.
>
> Marek,
>
> I understand that you, like me, you're just trying to advocate what appears
> to be best. I think we're both smart people and neither in disagreement just
> for the sake of it. I think ultimately that we'll just have to agree on
> disagreeing and move one with something. Preferably before this becomes an
> emotional argument.
I agree. :)
>
>> 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.
>
> I confess I'm confused now: until now I thought you wanted to add new
> pipe_format enums -- precisely to put in switch/case statements --, but it
> seems that what you really want is extending the struct
> util_format_description. Which is a substantially different conversation.
>
> Before I comment any further, could you succinctly describe, exactly how you
> envision to extend util_format_description to express what you need to know?
>
> If you could point these functions in the radeon code it would be good too.
>
> Jose
>
>
This change would be best to describe a vertex and texture fetch as
implemented by Radeons:
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index 2eb3e1b..8c4d67f 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -91,10 +91,11 @@ struct util_format_block
enum util_format_type {
UTIL_FORMAT_TYPE_VOID = 0,
- UTIL_FORMAT_TYPE_UNSIGNED = 1,
- UTIL_FORMAT_TYPE_SIGNED = 2,
- UTIL_FORMAT_TYPE_FIXED = 3,
- UTIL_FORMAT_TYPE_FLOAT = 4
+ UTIL_FORMAT_TYPE_FLOAT = 1,
+ UTIL_FORMAT_TYPE_INT = 2, /* signed/unsigned */
+ UTIL_FORMAT_TYPE_NORM = 3, /* signed/unsigned */
+ UTIL_FORMAT_TYPE_SCALED = 4, /* signed/unsigned */
+ UTIL_FORMAT_TYPE_FIXED = 5,
};
@@ -121,7 +122,7 @@ enum util_format_colorspace {
struct util_format_channel_description
{
unsigned type:6; /**< UTIL_FORMAT_TYPE_x */
- unsigned normalized:1;
+ unsigned is_signed:1;
unsigned size:9; /**< bits per channel */
};
Of course, Translate doesn't need any of this. Not only does Translate
know the input format, it also knows the output format. So it actually
knows 2 pipe formats for one fetch-and-store operation. If you have 2
pipe formats, it's easy to figure out the best mapping between them.
On the other hand, the vertex (or texture) fetch instruction, which is
also a fetch-and-store operation, only knows the input format. The
output is the untyped shader register. And we need to know whether
it's float or int. I think this matters to softpipe and llvmpipe as
well.
Now you can take a look at the function r600_vertex_data_type in
r600_asm.c:2020. It's a good example of what is going on. At the end
of the function, there is this piece of code:
if (desc->channel[i].normalized) {
*num_format = 0;
} else {
*num_format = 2;
}
0 means NORM, 2 means SCALED. And guess what... 1 means INT. I think
"num_format" stands for "numeric format". The function which is called
in is_format_supported is r600_is_vertex_format_supported in
r600_formats.h:84.
Note that r600 might be able to support SCALED textures too (I know I
had said the opposite, but I am not sure now after I read the docs
again). We only know SCALED doesn't work for 32 bits per channel, same
as with vertices. 8 bits and 16 bits per-channel SCALED textures might
work, but nobody tried that yet.
So now we are back to the discussion about the convert-to-float flag
in pipe_vertex_element and is_format_supported. I am not saying it's
wrong, I am just saying it's not clean. Either way, I will respect the
final decision of the implementers of this functionality.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
