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