[Mesa-dev] gallium scaled types

[Dave Airlie]

2011/9/16 Christian König <deathsimple at vodafone.de>:
> Am Freitag, den 16.09.2011, 08:40 -0700 schrieb Jose Fonseca:
>> ----- 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.
>>
>> > 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.
> Just as a side note: I already used those formats for g3dvl, and also
> had code for r600g to use them how Marek described it. But I removed
> this code before merging pipe-video with master, because I figured out
> why normalized textures didn't worked as I was expecting them to work
> and fixed that handling instead.

Yeah this sort of invalidates something we said earlier, so neither DX
or GL offer a way to expose proper SCALED textures, you have FLOAT or
INT, so we said earlier in this thread we'd accept that int textures
won't ever be interpreted as floats. If g3dvl can use these then we
need to accomodate that.

So we also need to add the as_float to the texture/surface paths if we
go that way or use the new types.

Sorry for breaking g3dvl, feel free to revert the r600g patch for now.
Dave.