> 1) I prefer this interface instead: > > void (*set_scissor_states)( struct pipe_context *, > unsigned start_slot, unsigned count, > const struct pipe_scissor_state * ); > > void (*set_viewport_states)( struct pipe_context *, > unsigned start_slot, unsigned count, > const struct pipe_viewport_state *); > > Both function should allow updating only a subset of all viewports and > scissors (from start_slot to start_slot+count-1). This is especially > important for meta ops (u_gen_mipmap, etc.), which need to update only > the first viewport (and no scissor), leaving the other viewports > unchanged. This idea is not new: the vertex buffer and compute sampler > functions have the start_slot parameter too.
It's obviously based on the d3d10 interface, it just seems like a lot simpler interface. I understand that gl does specify the start slot when updating the viewports, but I did think that explicitly specifying viewports from 0 up to the number of viewports set, was semantically very clear. > 2) What does cso_context need to keep a copy of all viewports for? All > meta ops need only one viewport, just as they need only one vertex > buffer and one constant buffer (and cso_context doesn't really allow > meta ops to use more than that). For example, see how the cso_context > interface for saving and restoring the constant buffer slot 0 looks > like. It's preferable to use the same mechanism unless there is a need > to have the save and restore functionality for all slots. It's a bit weird to say "none of the utils uses multiple viewports" given that this is the first commit that at all introduces the concept. What if something will? It's not a lot of code and it seemed to make sense to do it properly from the start. z _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
