fog with pixel shaders < 3.0

Stefan Dösinger stefandoesinger at
Mon Mar 12 07:39:51 CDT 2007

Am Montag 12 März 2007 13:16 schrieb H. Verbeet:
> No, but the hash table functions in utils.c should be generic enough
> to help at least a little bit with keeping track of the different
> states.
I am thinking more about completely removing a compiled shader rather than 
having 2 or more  gl shaders for one d3d shader.

> > If we want to manage multiple compiled shaders with fog on/off then we
> > should extend that to the whole parameter set. We already have sampler
> > type(2D, 3D, cube), texture transform flags(D3DTTF_PROJECTED) and now fog
> > and pixel format coming. My concern is that managing this will get too
> > expensive and grow the amount of linked glsl programs vastly.
> Up to a certain point. This should only be an issue for pre-2.0
> shaders, and MSDN does hint that changing some states (like eg. the
> sampler type) might cause a shader recompilation, so applications
> doing that will probably be in trouble on Windows as well.
Ah, good to know :-)

> I think it's important here to know what exactly is the problem, and
> under which conditions this happens. It would be a shame if we started
> adding lots of complexity because of this, only to find out later that
> it could have been avoided by eg. simply always using per vertex fog
> when a pixel shader is used.
Well, it won't be the always per vertex fog thing because we were doing that 
up to a patch my Vitaly, but agreed in general :-) . Its test case time :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the wine-devel mailing list