[Mesa-dev] gallium scaled types

[Marek Olšák]

On Fri, Sep 16, 2011 at 5:40 PM, Jose Fonseca <jfonseca at 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