Am 21.03.2018 um 19:23 schrieb Marek Olšák:
On Wed, Mar 21, 2018 at 2:15 PM, Christian König <christian.koe...@amd.com <mailto:christian.koe...@amd.com>> wrote:

    Am 21.03.2018 um 19:04 schrieb Marek Olšák:
    On Wed, Mar 21, 2018 at 10:07 AM, Christian König
    <christian.koe...@amd.com <mailto:christian.koe...@amd.com>> wrote:

        Am 21.03.2018 um 14:57 schrieb Marek Olšák:
        On Wed, Mar 21, 2018 at 4:13 AM, Christian König
        <ckoenig.leichtzumer...@gmail.com
        <mailto:ckoenig.leichtzumer...@gmail.com>> wrote:

            Am 21.03.2018 um 06:08 schrieb Marek Olšák:
            On Tue, Mar 20, 2018 at 4:16 PM, Christian König
            <christian.koe...@amd.com
            <mailto:christian.koe...@amd.com>> wrote:

                That's what I meant with use up the otherwise
                unused VRAM. I don't see any disadvantage of always
                setting GTT as second domain on APUs.

                My assumption was that we dropped this in userspace
                for displayable surfaces, but Marek proved that wrong.

                So what we should do is actually to add GTT as
                fallback to all BOs on APUs in Mesa and only make
                sure that the kernel is capable of handling GTT
                with optimal performance (e.g. have user huge pages
                etc..).


            VRAM|GTT is practically as good as GTT. VRAM with BO
            priorities and eviction throttling is the true "VRAM|GTT".

            I don't know how else to make use of VRAM intelligently.

            Well why not set VRAM|GTT as default on APUs? That
            should still save quite a bunch of moves even with
            throttling.


        I explained why: VRAM|GTT is practically as good as GTT.


            I mean there really shouldn't be any advantage to use
            VRAM any more except that we want to use it up as long
            as it is available.


        Why are you suggesting to use VRAM|GTT then? Let's just only
        use GTT on all APUs.

        Then we don't use the memory stolen for VRAM.

        See we want to get to a point where we have any ~16MB of
        stolen VRAM on APUs and everything else in GTT.

        But we still have to support cases where we have 1GB stolen
        VRAM, and wasting those 1GB would suck a bit.


    BO priorities and BO move throttling should take care of optimal
    VRAM usage regardless of the VRAM size. We can adjust the
    throttling for small VRAM, but that's about all we can do.

    Well at least on APUs move throttling is complete nonsense. VRAM
    should expose the same performance as GTT.

    So the only usage we have for VRAM is for special cases like page
    tables and to allow to actually use the stolen memory.

    VRAM|GTT doesn't guarantee that VRAM will be used usefully. In
    fact, it doesn't guarantee anything about VRAM.

    Why not? VRAM|GTT means that we should use VRAM as long as it is
    available and if it is used up fallback to GTT.

    When BOs are evicted from VRAM they are never moved back into it.
    As far as I can see that is exactly what we need on APUs.


I see. You don't want to use VRAM usefully. You just want to fill it up with something (anything) so that it's not unused.

Yes, exactly. The point is we really don't have any special use case for it on APUs any more on newer kernels/hardware.

We need a bit for firmware, but that is fixed and allocate at driver load time.

Page tables are still in VRAM, but at least for Raven that is just an issue that I didn't had free time to implement it otherwise.

If I could I would give the unused parts back to the OS for general purpose usage, but you need to reconfigure the northbridge to do that and well that is easier said than done.

Christian.


Marek

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to