[PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
Michel Dänzer
michel at daenzer.net
Fri Oct 26 09:33:31 UTC 2018
On 2018-10-25 7:57 p.m., Wentland, Harry wrote:
> On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
>> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>>>> I'm curious to know whether this will/could work over PRIME
>>>> I don't see why this shouldn't work over PRIME as long as the
>>>> presenting GPU supports the new variable refresh rate API, but
>>>> I know very little about prime, so maybe someone else can chime
>>>> in and give a better opinion.
>>> It won't work for displays connected to a secondary GPU, because
>>> those aren't hooked up to the Present extension directly.
>>>
>>> It can theoretically work with render offloading, if the primary
>>> GPU can scan out directly from the shared pixmap. This is only
>>> possible with current AMD APUs which support scatter/gather
>>> scanout (Carrizo and newer?).
>>
>> Actually only Carizzo and Stoney at the moment because this is
>> buggy on Raven. Not sure if that is a pure software or a hardware
>> problem.
>>
>> Christian.
>>
>>> One gotcha is that xf86-video-amdgpu currently doesn't allow
>>> flipping between buffers with different tiling parameters (BTW
>>> Harry, does that work with DC?), but that should be easy to fix.
>>
>
> Not currently. Fixable, but unfortunately not as easy as I'd hope.
> The good news is that I'm planning to rework that code so it would be
> easy to fix or should just happen on a per-flip basis.
FWIW, I wouldn't spend any effort specifically on making this work. It's
not intended to work with the non-atomic flip ioctl at least, and it
definitely doesn't work without DC, so xf86-video-amdgpu will have to
handle it anyway.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the amd-gfx
mailing list