Am 21.03.2018 um 19:23 schrieb Marek Olšák: > On Wed, Mar 21, 2018 at 2:15 PM, Christian König > <christian.koenig at amd.com <mailto:christian.koenig at 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.koenig at amd.com <mailto:christian.koenig at 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.leichtzumerken at gmail.com >>> <mailto:ckoenig.leichtzumerken at 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.koenig at amd.com >>>> <mailto:christian.koenig at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180321/117c2757/attachment-0001.html>
