[PATCH 3/5] wined3d: Prune invalid states from the state table.

[Stefan Dösinger]

On Friday 29 January 2010 00:55:19 Henri Verbeet wrote:
> Almost. The texture_stages limit is supposed to indicate the number of
> texture stages the GL implementation can support, I don't think
> there's a reason to change that. What needs to change is that we
> assign its value based on the fragment pipeline caps instead of based
> on the GL extensions.
Texture stages are a direct3d concept. On the GL side we have 
MAX_GENERAL_COMBINERS_NV, 8(atifs extension hardcoded), MAX_TEXTURES(ffp) or 
the arbfp shader instruction limit. How those translate into the d3d limit is 
an implementation detail of the fragment pipeline and none of the GL extension 
loading code's business.

Plus, we need the raw GL limit intact as well. Let's take for example gl 
max_textures vs gl max_samplers vs d3d MaxSimultaneousTextures. Assume a 
geforce 7 card. max_textures = 4, arbfs pipeline.

In this situation this code will result in a GL error:
glActiveTexture(GL_TEXTURE5);
glBindTexture(GL_TEXTURE_2D, tex);
glEnable(GL_TEXTURE_2D);

However, on the d3d side this is perfectly valid and working OK:
SetPixelShader(NULL);
SetTexture(0, tex);
SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTexture(1, tex);
SetTextureStageState(1, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTexture(2, tex);
SetTextureStageState(2, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTexture(3, tex);
SetTextureStageState(3, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTexture(4, tex);
SetTextureStageState(4, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTexture(5, tex);
SetTextureStageState(5, D3DTSS_COLOROP, D3DTOP_PREVIOUS);
SetTextureStageState(6, D3DTSS_COLOROP, D3DTOP_DISABLE);

So (gl)max_textures=4, (gl)max_samplers=16, (d3d)MaxSimultaneousTextures=8

Furthermore we can't store MaxSimultaneousTextures in the GL limits, as it can 
depend on the device creation parameters. E.g. the app creates the device with 
D3DCREATE_SOFTWARE_VERTEXPROCESSING. This way the vertex pipeline's limits 
don't have any relation to the GL vertex limits, and we don't know what the 
app will do when we initialize the adapter.

> > Please use the number of texture blend stages reported from the fragment
> > pipeline rather than gl_limits.texture_stages. texture_stages only works
> > with the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok
> > by chance on most GL cards).
> 
> If those aren't the same, the code initializing the texture_stages
> limit is broken, not the code using it.
Your code is manipulating the input into the pipeline code, it is talking in 
D3D terms, so the D3D limits apply, not the GL limits.

> > There's a deeper issue with how we manage texture limits, because
> > currently the extension loading code picks limits.texture_stages, already
> > anticipating which pipeline we'll choose later. We should handle this in
> > the way shader
> 
> True, but that code was there before the concept of a fragment
> pipeline was introduced in wined3d.
I introduced the separation of d3d fragment pipeline limits from gl fragment 
pipeline limits when I introduced the different fragment piplines - see the 
pipeline.get_caps() function. Later on I did the same for shader limits. It is 
far from perfect though, on the vertex side we're still mixing them up.

I can't find the original patch in git since it was a long time ago in spring 
08, here are a few following patches though:
9a6bc683e11bf508a37769640d56f201462b935a
462ddaa25404cd1a07135f5d7acdd2e298d7dfad