[PATCH 3/5] wined3d: Prune invalid states from the state table.
stefandoesinger at gmx.at
Fri Jan 29 06:07:52 CST 2010
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
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
More information about the wine-devel