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 <mar...@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 < > court...@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 <bri...@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 <i...@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@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >> >> >> >> -- >> Courtney Goeltzenleuchter >> LunarG >> >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> > -- Courtney Goeltzenleuchter LunarG
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
