On Wed, Mar 7, 2018 at 12:29 PM, Samuel Li <samuel...@amd.com> wrote:
> Why so complicated? If old user space compatibility is required, just use
It will always just work in that case and we can adjust for the
optimal scenario by default in all cases without requiring the user to
set misc parameters to tune their setup that may break in the future
or hide bugs because a user sets it and forgets it.
> On 2018-03-07 05:12 AM, Michel Dänzer wrote:
>> 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.
amd-gfx mailing list