On 19 April 2013 11:20, Stefan Dösinger stefan@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.