On 07.07.2016 16:43, Christian König wrote: > Am 07.07.2016 um 05:32 schrieb Michel Dänzer: >> On 06.07.2016 22:45, Tejun Heo wrote: >>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote: >>> >>>> Not being very familiar with the workqueue APIs, I'll describe how it's >>>> supposed to work from a driver POV, which will hopefully help you guys >>>> decide on the most appropriate alloc_workqueue parameters. >>>> >>>> There is one flip work queue for each hardware CRTC. At most one >>>> radeon_flip_work_func item can be queued for any of them at any time. >>>> When a radeon_flip_work_func item is queued, it should be executed ASAP >>>> (so WQ_HIGHPRI might be appropriate?). >>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwise >>> require a kthread w/ nice value at -20. Would that be the case here? >>> What are the consequences of the work item getting delayed? >> A page flip may be delayed to a later display refresh cycle. >> >> >>> Also, what kind of delays matter here? Is it millisec range or micro? >> It can be the latter in theory, but normally rather the former. > > Well to be precise with a typical 1920x1080@60 resolution you have about > 2.16ms time under ideal conditions for the flip. > > So using the high priority queue still sounds like a good idea to me. How did you arrive at 2.16ms? Userspace can call the ioctl up to one full refresh cycle ahead of time, which is ~16ms at 60 Hz. On the other hand userspace can also call the ioctl arbitrarily close to the vertical blank period, in which case even a delay of just 1ms (or even significantly less) may cause the flip to be delayed by one refresh cycle. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
