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

[Stefan Dösinger]

On Friday 29 January 2010 12:02:39 Henri Verbeet wrote:
> 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.
The name mostly. MaxSimultaneousTextures=8(with arbfp) doesn't come from any 
GL limit.

Plus, as a minor point, the initialization time. The d3d limits on paper 
depend on the device creation params, the gl limits do not.

> > 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 limit
> > ...
> 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.
>
> 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.
My preference would be this:

Put max_ffp_textures, max_ffp_texture_stages, the shader constant limits into 
a device->limits structure and initialize it at device creation time based on 
what the pipeline and shader backends report.

Alternatively, I am fine with renaming wined3d_gl_limits and selecting the 
pipeline and shader backend during adapter initialization as you suggest, as 
long as we separate the nvrc combiner limit from the d3d texture stage limit. 
If we ever implement a software vertex processing pipeline moving the d3d 
limit initialization back to the device creation code will be the least 
concern.