<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [radeon][TTM] Contention when evicting large buffers between VRAM and GTT"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92775#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [radeon][TTM] Contention when evicting large buffers between VRAM and GTT"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92775">bug 92775</a>
from <span class="vcard"><a class="email" href="mailto:michel@daenzer.net" title="Michel Dänzer <michel@daenzer.net>"> <span class="fn">Michel Dänzer</span></a>
</span></b>
<pre>(In reply to Shawn Starr from <a href="show_bug.cgi?id=92775#c0">comment #0</a>)
<span class="quote">> One solution discussed is to split up the transfer into smaller chunks in
> radeon_ttm.</span >
Specifically, here's how I think a fallback could be implemented in the kernel
driver which can never fail because of fragmentation or resource starvation:
During initialization, reserve some pinned GTT memory for bounce buffers. When
a BO can't be bound to GTT for eviction as in the case reported here, instead
do the eviction directly from VRAM to CPU domain in one or several passes of:
1. Copy part of the BO from VRAM to one of the reserved bounce buffers in GTT
using the GPU.
2. Copy that part of the BO from the bounce buffer to the BO's system RAM pages
using the CPU.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>