[PATCH 2/7] wined3d: Store vs_clipping in the adapter

Henri Verbeet hverbeet at gmail.com
Fri Apr 19 09:26:18 CDT 2013


On 19 April 2013 11:20, Stefan Dösinger <stefan at codeweavers.com> wrote:
> Potential alternatives include keeping the status quo or introducing a
> separate structure that holds these derived limits that is owned by the
> device and linked in the contexts. We could also put it into gl_info,
> but I dislike this idea because these limits are not GL limits, but
> limits of our shader and fixed function pipeline implementations.

I think we'll want a separate structure for this. Note that you
essentially have two different kinds of data you're concerned with
here though. One is derived state like e.g. the texture unit map, the
stream info, or the view_indent from patch 1/7. We don't really want
that in wined3d_state, because there's no reason for e.g. every
stateblock to have a copy of that. Having the derived state structure
be owned by the device is probably ok, although there may also be
something to be said for making it part of the context instead. The
other type of data is immutable data like derived caps and limits, as
in this patch and following ones. In principle the adapter is the
right place for that, but I do think we want a separate structure for
that, and probably a pointer to it in the context, for similar reasons
as having one to gl_info. Arguably things like the state table, format
info and the shader backend would belong in the same structure. I.e.,
essentially we'd have a setup like wined3d_gl_info, but for more
wined3d specific / derived info.



More information about the wine-devel mailing list