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

[Corbin Simpson]

Whee, this is quite the Reply-to list. :3

My approach in r300_chipset.c
(http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_chipset.c
for those of you without a current checkout) is still there, and is
largely the way that I considered best for handling this kind of
thing. It's not exactly a table, but it's got a lot of the same
properties and I felt it was a pretty good way to approach the problem
of doc'ing and handling errata.

For your example of an erratum that plagues only one specific chipset,
I'd just set the default to be "No, I don't have that problem," and
then in the switch statement, set it to "Yes, I do have that problem,"
for that chipset.

Hope this helps.
~ C.

2011/3/9 Christian König <deathsimple at vodafone.de>:
> 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.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>