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

[Marek Olšák]

st_viewport has nothing to do with the viewport. It's used if libGL doesn't
expose __DRI_USE_INVALIDATE, so I don't think it's safe to remove it. If
Driver::Viewport is about to removed, the code of st_viewport should be
moved somewhere else.

Marek


On Wed, Nov 20, 2013 at 12:53 AM, Courtney Goeltzenleuchter <
courtney at lunarg.com> wrote:

> 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?
>
> Courtney
>
>
> 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
>>>>> 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
> LunarG
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131120/aa5f8594/attachment.html>