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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to