[5/8] WineD3D: Add a more formal framework for driver quirks

[Henri Verbeet]

2009/4/12 Stefan Dösinger <stefan at codeweavers.com>:
> I accidentally deleted the mail in my inbox, so that reply is without a proper
> in-reply-to tag. Here's the archive for reference:
> http://www.winehq.org/pipermail/wine-devel/2009-April/074718.html
>
>> - I don't like how much information specific to constant fixups the
>> table contains.
> There is a lot of intended redundancy here. The minimum we need is the flag to
> use the ARB or GLSL constant value. I want some additional safeguards to make
> the fixup noisy if one of the assumptions we make about the driver isn't true
> any more.
>
> The patches here only handle constants, but I want to do the same for
> varyings.
>
> I don't like the idea of using a callback function to apply the fixups because
> it would repeat quite a bit of value checking and FIXME writing code for
> different cards, just with different constants in the code.
>
Well, the main fixup I see you doing is replacing the GLSL limit with
the ARB one. "GLSL" and "HARDCODED" are never used, afaik. I don't see
how you would need more than a single function for that. Even for
"HARDCODED" you could just create a single function with a lookup
table, although I don't see "HARDCODED" getting much use in the first
place.

> I want to keep the driver vendor match separated from the card match to allow
> defining fixups that apply to all cards run by a driver from a specific
> vendor. A later patch adds a fixup that uses the ARB constant limits on all
> cards if we're running on a apple driver. There are other ways to do this,
> like returning a matching score and using the best match, or merging two
> fixups into one. I think that my approach matches what we want to do best and
> is simpler than trying to merge fixup descs.
>
Well, it's not particularly hard to define a wildcard for the vendor
and card fields to match eg. everything on a certain platform / driver
vendor or everything from a certain hardware vendor.

>> - Why do you store the quirk table in gl_info? It's never used from
>> there. (I realise the next couple of patches do use it from there).
>> ...
>> and just add a DWORD "quirk_flags" to gl_info.
> My patches add two fields that are accessed from other places in the code.
> There may or may not be more in the future. I prefer to have one pointer in
> the gl_info structure than multiple DWORDs containing quirk info, but I am
> flexible with this.
>
You can store the information in a structure if you like, but that's
not the point. The point is that you don't actually use it in this
patch, and that struct driver_quirk is the wrong structure to store.
You want to know what fixups are active, not which entry in the quirks
table caused them. Not storing the entry from the quirks table also
avoids the problem you mention with "merging" fixups. You just apply
the fixups in order, and add the appropriate flags.