WineD3D State management - going live(TM)

Stefan Dösinger stefandoesinger at gmx.at
Mon Oct 23 06:46:31 CDT 2006


> 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).
Well, there is not much difference between samplers, shaders and render 
states, the idea is the same in spirit, just the code is a bit different. The 
whole sampler settings, and the shader constant can be handled as one state 
in the table, and updates can be caused in the same way. So the function 
verifying and setting sampler states will be a normal function like a 
function for a render state, just a bit bigger, and the whole sampler state 
block will likely be marked dirty every frame. There is no additional magic 
involved in activating updating the samplers as a whole. Simmilar for shader 
constants.

e.g. Set{Vertex/pixel}ShaderConstant* markes STATE_SHADERCONSTANT dirty, which 
is handled by func_shaderconstant(state, stateblock). SetPixelShader and 
SetVertexShader dirtify STATE_PSHADER/STATE_VSHADER, and the func_pshader / 
func_vshader call func_shaderconstant if we use glsl shaders to be sure that 
the shader constants are correct. (The details may look slightly different, 
but that is the idea basically)

> > 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..
Can you describe what this would look like in detail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20061023/09862841/attachment.pgp


More information about the wine-devel mailing list