WineD3D State management - going live(TM)
ivg231 at gmail.com
Mon Oct 23 05:36:13 CDT 2006
>> 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..
More information about the wine-devel