WineD3D State management - going live(TM)

[Ivan Gyurdiev]

>> I don't like how the number of things staying "as they are right now" is
>> growing, while the number of things being changed remains confined to
>> render states. To have a proof-of-concept state management system, it
>> would be best to take things that are as different as possible, and
>> manage to get them successfully updated via the new state manager.
>> Otherwise you won't find out whether the design is flawed or not until
>> much later.
>>     
> Agreed, in theory. But I also think that we shouldn't try to put different 
> things in one model by force. If some things work differently, why shouldn't 
> we handle them seperately?
>   
Because that creates confusion and disorder - the idea is to move from 
chaos (gl code in drawprim, shaders, device.c) to order (gl code in one 
place, following a uniform pattern, with the ability to do locking 
and/or switch the gl backend).
> Shader constants are different from fixed function things in two ways: There 
> is a dynamic number of them,
That's only a problem, because you keep trying to force everything into 
a constant array :)

>  and there are no dependencies between 2 shader 
> constants. So there is no use for a table like the fixed function elements, 
>   
Sure there is... it creates a uniform structure for applying states, 
bringing some benefits as described above.
Dirty-tracking is only one of the goals, and the stateblock already does 
some of that..