[Mesa-dev] [PATCH] mesa: Change driver interface for ARB_viewport_array
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
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:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
>>>> 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
>> 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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev