On 11/19/2013 04:53 PM, Courtney Goeltzenleuchter 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?

For multiple viewports, I think you only have to be concerned with the st_atom_viewport.c code. Have you looked at that?

-Brian



Courtney


On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul <bri...@vmware.com
<mailto: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
            <mailto: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 <mailto:mesa-dev@lists.freedesktop.org>
    http://lists.freedesktop.org/__mailman/listinfo/mesa-dev
    
<https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=VA9eAusZ3%2F58PQhMUXx1cXtP63BThETAT9Sz8PNRq0o%3D%0A&s=5f6224c40a28fafa01d3c8134d9417d64470d4ee9013c10642127799ff93258d>




--
Courtney Goeltzenleuchter
LunarG


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to