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

[Courtney Goeltzenleuchter]

I've got st_atom_viewport.c covered, that one is easy.

Marek's comment is what I'm looking for. As I was looking at the
possibility of removing the Driver::Viewport I wanted to make sure I
understood possible ramifications. I will not include the removal of
Driver::Viewport or Driver::Scissor in my ARB_viewport_array patches.

Thanks,
Courtney


On Tue, Nov 19, 2013 at 5:13 PM, Marek Olšák <maraeo at gmail.com> wrote:

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


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