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