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

[Henri Verbeet]

On 29 January 2010 11:01, Stefan Dösinger <stefandoesinger at 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.