----- 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.

Jose

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to