[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel - bugzilla-daemon

From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel
Date: Wed, 22 Nov 2017 11:56:41 +0000	[thread overview]
Message-ID: <bug-103100-502-5z4hpFRfps@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-103100-502@http.bugs.freedesktop.org/>

[-- Attachment #1.1: Type: text/plain, Size: 1213 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

--- Comment #6 from Christian König <ckoenig.leichtzumerken@gmail.com> ---
(In reply to Michel Dänzer from comment #4)
> Christian, might it be possible to e.g. maintain a list of per-VM BOs which
> were evicted from VRAM, and try to move them back to VRAM as part of the
> existing mechanism for this (for "normal" BOs)?

That would certainly be possible, but I don't think it would help in any way.

The kernel simply doesn't know any more which BOs are currently used and which
aren't. So as soon as userspace allocates more VRAM than physical available we
are practically lost.

In other words we would just cycle over a list of BOs evicted from VRAM on
every submission and would rarely be able to move something back in.

What we could do is try to move buffers back into VRAM when memory is freed,
but that happens so rarely as well that it probably doesn't make much sense
either.

Can somebody analyze exactly why those games are now slower than they have been
before? E.g. which buffers are fighting for VRAM? Or are they maybe fighting
for GTT?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2146 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel