[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 12/01/17 12:09 AM, Cheng, Tony wrote:
> Vblank interrupt fires as soon as the last line of active region is
> scanned out.
> VSync interrupt fires at the vsync.
> VUpdate interrupt fires HW is ready to scan out a new frame, this include
> latch on double buffer registers, starting memory request etc.
> 
> We use VUpdate to accommodate free sync, as in free sync, blank region
> is variable and a frame can be terminate as soon as new surface address
> is written to register.  If we use vblank interrupt will be fired too
> early and might not stretch frame time properly.

What does "fired too early" and "might not stretch frame time properly"
mean exactly?

Is it that the timestamp reported to userspace, which is supposed to
correspond to when scanning out the next frame starts, would be
incorrect? Or something else?


Apart from being too late for some use cases of the
DRM_IOCTL_WAIT_VBLANK ioctl, there's another issue with the VUPDATE
interrupt: Because it's processed after the PFLIP interrupt, the DRM
vblank sequence number is only incremented after a corresponding page
flip completion event is sent to userspace, so the vblank sequence
number in the event is 1 too low.

I'd like to help come up with a solution for this, but I need to
understand the concerns about the VBLANK interrupt vs FreeSync better.


> I think us DAL guys might not have the full understanding of DRM
> vblank machinery.  Is there some document we can go read up on to make
> sure all our assumption is correct?

I'm not sure, but I've been involved with it pretty much since the
beginning, so I can explain some things about it. :)


> From our perspective it seems some of the DRM vblank machinery (or the
> way we implement them) is redundant as our HW can do things that we
> queue off a work item to do automatically if we configure the HW correctly.

Do you mean amdgpu_flip_work_func? I'm not sure how the HW could
automatically wait for fences to signal before executing the flip, but
maybe it could delay the flip until the frame count passes a threshold?
Or are you thinking of something else?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer