[Mesa-dev] Coding or Table based approach for r600g? (was RFC: 0001-r600g-R700-can-do-more-than-8-tex-and-vtx-clauses.patch)

[Christian König]

Am Mittwoch, den 09.03.2011, 07:00 +0100 schrieb Ferry Huberts:
> Hi,
> 
> Disclaimer: I'm just a list reader.
> 
> 
> I've been wondering about this for a while: is there a structure in
> which information is stored that is tied to the card with which the code
> is dealing, and if not, isn't it a good idea to introduce one?
> 
> This patch triggered this again for me because it seems that such a
> structure would be benefical both for performance and for code readability.
> 
> The structure would get filled with information only once: when the card
> is detected.
> 
> For the case of the patch this would mean that the function
> 'r600_bc_num_tex_and_vtx_clauses' would get replaced by retrieving a
> field from the structure, since the function only returns a constant
> (dependent on the type of the card).
Hi,

indeed a lookup table based approach has it's advantages, you could have
a table for chipset features, chipset family informations and maybe also
for alu opcodes. It's more readable and getting a specific information
is faster (at least most of the time), and we already use this approach
for the tgsi->alu opcode mapping,

The major downside of such an approach is it's inflexibility, for
example if a specific information depends in 99% of the cases on the
chipset family you would normally put it into the table for the chipset
family, but just imaging that only one chipset has a bug and can't do
the specific feature. This would place you in the need to move this
information into the chipset table. Remember this is just an (probably
unrealistic example), but it should show the general problem.

I don't want to make such a design decision on my own so I cc'ed
everybody who committed patches into r600g in the last couple of weeks.

So hey guys what do you think about it?

And to make my own opinion clear:
I also really prefer tables, but didn't used them in the past because I
wasn't 100% sure which feature depends on what and which approach we
really want.

Regards,
Christian.