On 2018-03-07 11:04 AM, Christian König wrote: > Am 07.03.2018 um 10:53 schrieb Michel Dänzer: >> On 2018-03-07 10:47 AM, Christian König wrote: >>> 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. >>> >>> So as long as we don't want a severe performance penalty when you >>> combine old userspace with new kernel using a kernel parameter to force >>> scanout from GTT is not possible. >> That means we either need to come up with a different workaround for >> hardware issues transitioning between scanout from VRAM and GTT, or we >> can't scan out from GTT in that case. > > What exactly was the problem with the transition from VRAM to GTT? > > I mean what we can rather easily do is check where the existing BO is > pinned and then always pin into the same domain on page flip. Yeah, something like that could work. In which case, all that's needed is a way for userspace to know that GTT scanout can work, right? With that information, it can manage the domains of scanout BOs as it wants. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
