Am 19.03.2018 um 20:39 schrieb Marek Olšák:
On Mon, Mar 19, 2018 at 3:27 PM, Christian König <[email protected] <mailto:[email protected]>> wrote:

    I think that the consensus with Alex and me is that we should
    avoid exactly that.

    Overriding the preferred domain in the kernel is a no-go for that
    patch set, so please implement the discussed changes in Mesa.


I don't see how Mesa can make a smarter decision than the kernel. If you overwrite the preferred domain of the buffer in the kernel, there will be no ping-ponging between domains. Mesa never changes the initial preferred domain.

Yeah, but it can set the initial domain based on what it knows how the buffer will be used.

E.g. when scanout from GTT is supported we would like to always set the initial domain as GTT instead of VRAM.

Christian.


Marek


    Regards,
    Christian.


    Am 19.03.2018 um 20:22 schrieb Li, Samuel:

        I agree with Marek/Michel: since kernel sets the domain before
        scanning out, it shall update the preferred domain here too.

        Regards,
        Samuel Li


            -----Original Message-----
            From: Koenig, Christian
            Sent: Thursday, March 08, 2018 4:07 AM
            To: Michel Dänzer <[email protected]
            <mailto:[email protected]>>; Li, Samuel
            <[email protected] <mailto:[email protected]>>; Alex
            Deucher <[email protected] <mailto:[email protected]>>
            Cc: amd-gfx list <[email protected]
            <mailto:[email protected]>>
            Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather
            display support

            Am 08.03.2018 um 09:35 schrieb Michel Dänzer:

                On 2018-03-07 10:47 AM, Christian König wrote:

                    Am 07.03.2018 um 09:42 schrieb Michel Dänzer:

                        On 2018-03-06 07:23 PM, Christian König wrote:

                            E.g. the last time I tested it placing
                            things into GTT still
                            resulted in quite a performance penalty
                            for rendering.

                        FWIW, I think the penalty is most likely IOMMU
                        related. Last time I
                        tested, I couldn't measure a big difference
                        with IOMMU disabled.

                    No, the penalty I'm talking about came from the
                    ping/pong we did with
                    the scanout buffers.

                    See when I tested this the DDX and Mesa where
                    unmodified, so both
                    still assumed VRAM as placement for scanout BOs,
                    but the kernel
                    forced scanout BOs into GTT for testing.

                    So what happened was that on scanout we moved the
                    VRAM BO to GTT

            and

                    after unpinning it on the first command submission
                    which used the BO
                    we moved it back to VRAM again.

                In the meantime, I've had the same idea as Marek:
                Can't the kernel
                driver simply change the BO's preferred domain to GTT
                when scanning
                out from it? Then it won't move back to VRAM.

            Yes, I've considered this as well.

            But I think making the decision in Mesa is the cleaner
            approach.

            E.g. so far we only override the placement decision of
            userspace for two
            reasons:
            1. We where running out of memory in VRAM.
            2. We have a hardware restriction which makes VRAM usage
            mandatory.

            And even then we never adjust the placement permanently,
            we just
            temporary moved the buffer where it was needed and moved
            it back after
            the operation completed.

            Additional to that Mesa might want to set even more flags
            and/or changes
            it's behavior. E.g. use a tilling mode which both importer
            and export in an
            A+A laptop understands etc...

            Regards,
            Christian.


    _______________________________________________
    amd-gfx mailing list
    [email protected] <mailto:[email protected]>
    https://lists.freedesktop.org/mailman/listinfo/amd-gfx
    <https://lists.freedesktop.org/mailman/listinfo/amd-gfx>



_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to