[Mesa-dev] [PATCH 1/4] gallium: Add support for multiple viewports

[Marek Olšák]

On Thu, May 23, 2013 at 11:59 PM, Zack Rusin <zackr at vmware.com> wrote:
>> 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.

The number of viewports set doesn't really matter. On latest hardware,
there are always 16 viewports. And we usually implement the union of
both GL and D3D. It would be reasonable to have the start_slot
parameter for pretty much every client (OpenGL, hardware drivers, and
internal Mesa meta ops) except D3D (which isn't even present in the
repository).

>
>> 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.

I can imagine u_gen_mipmap using layered rendering (a very important
feature of geometry shaders), however nothing comes to mind which
would need to use multiple viewports. If we ever need the support for
multiple viewports in meta ops / internal rendering code in the middle
application rendering, we can add the necessary code to cso_context.
Until then, it's just burning CPU cycles for nothing.

Marek