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

Stefan Dösinger stefan at codeweavers.com
Sun Apr 12 10:02:43 CDT 2009


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.

> - The "apple" field is weird. If you're going to have a callback
> function you might as well match that information there, if
> appropriate. On the other hand, I don't think you really need the
> callback function, you only match on vendor and card anyway.
All non-apple platforms have the same graphics driver, just the Apple drivers 
have their own weirdness that does not occur anywhere else. Its mostly many 
unsupported features that are advertised and software emulated which we have 
to filter out. All other platforms share the same driver anyway, even Windows 
to a certain extend.

I can replace this with a driver vendor enum or a driver vendor matching 
function. However, I am prepared to adjust the setup in the future if 
$NEWWEIRDRIVERVENDOR pops up(e.g. Gallium3D) that has different requirements.

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.

> - What is the point of only allowing one fixup per card, and then
> adding QUIRK_NO_SANITY_CHECK to allow more fixups? You might as well
> just allow multiple fixups and apply them in the order they're
> defined.
See above - generic fixups for a driver vendor that applies across cards. 
Obviously a Geforce 8 has different uniform or varying limits than a Intel 
GMA 950, but in both cases the GLSL uniform info is no good and we should use 
the ARB one instead.

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



More information about the wine-devel mailing list