Am 08.03.2018 um 09:35 schrieb Michel Dänzer: > On 2018-03-07 10:47 AM, Christian König wrote: >> Am 07.03.2018 um 09:42 schrieb Michel Dänzer: >>> On 2018-03-06 07:23 PM, Christian König wrote: >>> >>>> E.g. the last time I tested it placing things into GTT still resulted >>>> in quite a performance penalty for rendering. >>> FWIW, I think the penalty is most likely IOMMU related. Last time I >>> tested, I couldn't measure a big difference with IOMMU disabled. >> No, the penalty I'm talking about came from the ping/pong we did with >> the scanout buffers. >> >> See when I tested this the DDX and Mesa where unmodified, so both still >> assumed VRAM as placement for scanout BOs, but the kernel forced scanout >> BOs into GTT for testing. >> >> So what happened was that on scanout we moved the VRAM BO to GTT and >> after unpinning it on the first command submission which used the BO we >> moved it back to VRAM again. > In the meantime, I've had the same idea as Marek: Can't the kernel > driver simply change the BO's preferred domain to GTT when scanning out > from it? Then it won't move back to VRAM. Yes, I've considered this as well. But I think making the decision in Mesa is the cleaner approach. E.g. so far we only override the placement decision of userspace for two reasons: 1. We where running out of memory in VRAM. 2. We have a hardware restriction which makes VRAM usage mandatory. And even then we never adjust the placement permanently, we just temporary moved the buffer where it was needed and moved it back after the operation completed. Additional to that Mesa might want to set even more flags and/or changes it's behavior. E.g. use a tilling mode which both importer and export in an A+A laptop understands etc... Regards, Christian.
