<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Performance regression with various games in drm-next-amd-staging Kernel" href="https://bugs.freedesktop.org/show_bug.cgi?id=103100#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Performance regression with various games in drm-next-amd-staging Kernel" href="https://bugs.freedesktop.org/show_bug.cgi?id=103100">bug 103100</a> from <a class="email" href="mailto:ckoenig.leichtzumerken@gmail.com" title="Christian König <ckoenig.leichtzumerken@gmail.com>"> Christian König</a> <pre>(In reply to Michel Dänzer from <a href="show_bug.cgi?id=103100#c4">comment #4</a>) > 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>