Opengl states in wined3d

Jason Green jave27 at gmail.com
Mon Jun 26 21:40:16 CDT 2006


On 6/25/06, Stefan Dösinger <stefan at codeweavers.com> wrote:
> The way opengl states are managed in wined3d at the moment is a bit messy and inefficient.

Agreed.  :-)

> * Brute force applying opengl states is likely to re-set the old state
> unnecessarily. Opengl does not assure that redundant calls are cheap.
> * if an application sets and resets a state for some reason between 2 drawprim
> calls that involves 2 not really necessary opengl state switches

I have this problem with Fog settings in the case of shaders.  If I
set & restore the fog states on each drawPrimitive, it will drop the
fps from 1250 to about 1000 in the Dolphin demo compared to just
setting it once and leaving it.  I've been holding off on a patch
(pretty much taken from Roderick Colenbrander) for this reason.  At
the moment in current git, fog is broken when used with shaders
(Dolphin demo and Tomb Raider Legend are affected).

> I can think of a few ways to solve this:
> * Do not do any opengl changes in SetRenderState, and apply all states in
> drawprim. This way UnlockRect and Blt don't have to care for resetting the
> things they changed and redundant changes can be catched nicely

This style is probably the best, since we (hopefully) don't have to
change much between drawPrim calls.   Just have a function which
compares the current GL state to the desired (cached) state, and
change only what's necessary.  However, some things (as you mentioned)
can be changed safely during SetRenderState, and that's outside of the
drawPrim loop, so hopefully it's just once per scene.  Though, every
game acts a bit differently, so it's tough to say how one method will
work over another.  But the caching method seems the cleanest to me.

> To avoid re-setting an old setting again the current opengl state could be
> stored in the d3ddevice. I think this should be done in any case, and
> depending on the nature of some parameters the opengl state or the d3d state
> should be kept in there(or both).

Agreed.

> I also think we should try to get rid of as much things as possible in
> drawprim. I do not mean entirely removing it, but having a simple flag which
> tells if a bigger number of states needs attention, like last_was_rhw does. I
> think about adding a last_was_blit flag which is set in BltOverride and
> UnlockRect.

Yep.


So, let's get a final game plan together and I can start the process
with the fog patch, then we can start cleaning up everything else
(which will be a fairly large undertaking but can be done in small
chunks).

Jason



More information about the wine-devel mailing list