-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-19 16:26, schrieb Henri Verbeet:
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.
My plan is to move the tex unit map and stream info into the context. This is fairly easy to do because it's already the context that triggers the update of these data structures.
The tricky bit is the lowest_disabled_stage because we have two pieces of code that use it. One is wined3d_device_set_texture_stage_state, which uses it to find nop state changes. The other one are the state application function and device_map_fixed_function_samplers. The state seems like the best place for this, as both the device and command stream have a copy of the state where they can keep their version of this value up to date.
IMHO it makes sense to keep view_ident close to the view matrix, as there's a pretty direct relationship between them. The other place where it could go is /dev/null, I doubt that it has a noticeable performance impact. This needs some benchmarking though.
load_base_vertex_index can probably go into the context. At least I don't see a reason that speaks against this.
There's a related situation I'm not quite happy with: The dirty states are stored in the context, but the values that should be set are not. For now I've kept this setup in my command stream patches and didn't run into problems. There may be a nicer approach though.
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.
Works for me.