[Mesa-dev] [PATCH] mesa: Change driver interface for ARB_viewport_array

Courtney Goeltzenleuchter courtney at lunarg.com
Tue Nov 19 15:53:13 PST 2013

The Gallium state tracker has a st_viewport that it puts into
driver->Viewport function table.

It's not clear to me how _NEW_VIEWPORT replaces the function of the
Driver->Viewport call.

Is it really safe to remove the driver->Viewport call for Gallium?


On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul <brianp at vmware.com> wrote:

> On 11/04/2013 11:43 AM, Ian Romanick wrote:
>> Hash: SHA1
>> On 11/01/2013 04:12 PM, Francisco Jerez wrote:
>>> Ian Romanick <idr at freedesktop.org> writes:
>>>  On 11/01/2013 02:04 PM, Courtney Goeltzenleuchter wrote:
>>>>> [...]
>>>> More often, the dd_function_table functions allow core Mesa to
>>>> signal the driver driver that something happened... and the
>>>> driver may need to do something in response.  For DRI2 drivers,
>>>> the Viewport function is a good example.  DRI2 drivers use that
>>>> signal as a hint that the window may have been resized.
>>>> Other dd_function_table functions are used by core Mesa to
>>>> request the driver create or destroy some resource (e.g., texture
>>>> storage).
>>>> If it weren't for the way nouveau used the DepthRange and Scissor
>>>> hooks, I think we could just about get rid of them altogether.  I
>>>> wish that driver just used the dirty state bits like everyone
>>>> else. :(
>>> Cases like the new dd_function_table::Scissor and ::Viewport hooks
>>> introduced in this patch series are the reason why nouveau tends
>>> to prefer overriding the dd_function_table to keep track of state
>>> changes rather than looking at the ctx->NewState bits, because the
>>> latter tend to be very coarse-grained -- e.g. there's one big
>>> _NEW_TEXTURE flag for all the state of all texture units while
>>> nouveau is able to update a subset of the texture state
>>> independently for only those texture units that have changed.
>>> With the dd_function_table interface proposed in this patch series
>>> it would be possible for the drivers to update the state of each
>>> viewport in the viewport array independently, which might be
>>> beneficial for some hardware someday, removing ::DepthRange and
>>> ::Scissor would preclude that possibility.
>> Right... I wonder if we might be better of just tracking a bit per
>> viewport in the gl_context.  I'm assuming we'll end up with something
>> like:
>>      struct gl_viewport_attrib Viewports[MAX_VIEWPORTS];
>> in the gl_context.  It would be easy to add
>>      GLbitfield  _DirtyViewports;
>> along side it.  The various Viewport and DepthRange functions would
>> set bits in that field along with _NEW_VIEWPORT.  Drivers that care
>> could examine (and clear) those bits.
>> We'd do similar for Scissor.
>> Looking at the i965 hardware (and our driver architecture), I believe
>> we have to upload all of the viewports anytime there's a change
>> anyway.  The viewports are just stored as an array in a BO.  See
>> gen7_upload_sf_clip_viewport and similar functions.
>> Marek:  Do you know what Radeon / Gallium want?
> The gallium interface takes a start,count array of viewports.  The st/mesa
> state tracker could use the bitfield to determine the changed range.  But
> we also have the CSO module to help filter out redundant state changes.
> -Brian
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Courtney Goeltzenleuchter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131119/0c803351/attachment.html>

More information about the mesa-dev mailing list