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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 6 on bug 103100 from
(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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux