On 29 January 2010 11:01, Stefan Dösinger stefandoesinger@gmx.at wrote:
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.
Yes, that's why the value of limits.texture_stages should be based on the fragment pipe caps instead of the detected extensions. You also seem to have a problem with storing derived limits in wined3d_gl_limits, but I don't see why. Where the limit is stored is a separate issue from what it contains though.
Plus, we need the raw GL limit intact as well. Let's take for example gl
We could add e.g. the general combiner limit to wined3d_gl_limits if needed, but with that being a pipeline specific detail we might as well keep that internal to the specific implementation. If it means anything, I'm not entirely happy with shader backend specific limits being exposed through wined3d_gl_limits either.
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
Sure, but I don't see how that's relevant? It's also a bit silly to enable fixed function texturing when you're using arbfs.
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.
Which we don't actually implement, and probably never will. In practice, all the limits are adapter limits, and things like shader backend and fragment pipe could be selected during adapter initialization instead of device initialization as well. If that ever changes it's of course trivial to split gl_info into a device specific part and an adapter specific part, or even move the entire thing to the device.
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.
I think this is a silly distinction, D3D limits are clearly derived from the capabilities of the GL implementation. In fact, a number of limits in there are derived limits, because they take things like quirks and registry settings into account. I'd be willing to rename "struct wined3d_gl_limits" to "struct wined3d_limits" though.
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
I guess those slipped by.