On 04.08.2016 19:12, Daniel Stone wrote:
On 4 August 2016 at 11:01, Michel Dänzer michel@daenzer.net wrote:
On 04.08.2016 18:51, Daniel Stone wrote:
On 4 August 2016 at 04:39, Michel Dänzer michel@daenzer.net wrote:
Patch 6 extends the ioctl with new flags, which allow userspace to explicitly specify the target vblank seqno. This can also avoid delaying flips in some cases where we are already in the target vertical blank period when the ioctl is called.
Is there open userspace for this?
Sure, referenced in patch 6:
https://cgit.freedesktop.org/~daenzer/xf86-video-ati/commit/?id=fc884a8af253...
https://cgit.freedesktop.org/~daenzer/xf86-video-amdgpu/commit/?id=b8631a9ba...
[...]
The only change compared to the existing ioctl is that userspace can ask for a flip to take effect in the current vblank seqno. The code added by the patch checks for target vblank seqno > current vblank seqno + 1 and returns -EINVAL in that case. This is also documented in drm_mode.h.
Is there any particular benefit to having split absolute/relative modes in this case? Personally I'm struggling to see the use of relative.
See the userspace patches above. It allows userspace to set the target to the current/next vblank seqno without a DRM_IOCTL_WAIT_VBLANK round-trip (which could also result in the target getting delayed by one frame compared to using a relative target directly).
Is all this tested somewhere?
Yes, I've been using it for a while on all my machines.
I mean in a test suite. :)
Not yet. Are you thinking of intel-gpu-tools, or something else?