[1/10] WineD3D: Add extension information to the states

[Stefan Dösinger]

> 1. Does not scale to more complex support checks. I suspect you'll have
> to have to rewrite this as soon as a case comes up that requires more
> than a single support check to establish support. A function pointer
> may
> help here.  It would also be interesting to look at similarities and
> differences with the ffp pipeline replacement - which is essentially
> the
> same thing on a much larger scale, where multiple states are replaced
> rather than a single state. Can these support checks handle the case
> where an extension would control replacing a group of states ?
A function pointer is a nice idea actually. I don't think we'll ever need
more than one extension per state line though, and the current scheme can
happily deal with two optional extensions(as a later patch dealing with
conditional NP2 textures will do). I don't expect that any new function will
come around that needs two extension checks at the same time since the fixed
function pipeline in both gl and d3d is in its final state and no new
features will come up, and shaders are well-standardized.

IMO the current way is easier to read, and until we need a more flexible
solution I'd pledge to keep the current code, since no matter what we(I)
would have to rewrite it. It is a pain to rewrite/modify a set of patches so
I don't want to do it unless we're certain we'll need it

> 2. Not necessarily relating to this patch, but in general I would be
> wary of trying to replace every if check with a pointer. Splitting on
> extension support is probably ok.
It is a performance consideration. The point of doing this is to coalesce if
checks into a function pointer abstraction layer that exists anyway. Those
if checks can be evaluated at device creation time, so there's no need to
run through them every time the state is applied.

The bigger picture is that we have 3 function pointer abstraction layers we
can't get rid of: The vtables(we really want inheritance), the state table
and the shader backend. My idea is to merge as many if checks as possible
that can be determined at object creation time into these anyway-existant
abstraction layers. (Of course with the vtables that's a bit ugly, unless we
generate vtables dynamically)