Issues adding driver support for present extension

[Keith Packard]

Frank Binns <frank.binns at imgtec.com> writes:

> The driver is only waiting for any rendering to the back buffer before 
> doing the flip.

I think we need a more sophisticated kernel interface then. One kludge
you could try is to block the client waiting for rendering to complete
before delivering the present request to the server? Or, figure out how
to get an event from the kernel to notify when the rendering was
complete and not replace the existing flip until that happens?

> This happens in the non-async case in that once the the flip is 
> initiated, i.e. we now have a pending flip, if another swap comes in for 
> the same MSC then we can't abort the pending flip.

Correct. That's what we're trying to "fix" with the current code, but
it's clearly not solving the whole problem. We want to be able to
substitute a new buffer for the pending flip.

The case in question is for handling multiple present requests within
the same frame. The obvious case is triple buffering, where the client
wants to generate frames as fast as possible, and then have the most
recently completed frame appear on the screen without tearing. The
current code tries to do this by not sending the flip to the kernel
until the vblank event is delivered to the server.

One can imagine changing the kernel interface so that a new flip request
would replace a pending one. The kernel could (presumably) detect when
the new flip buffer went idle and do the replacement then, rather than
immediately when the flip call was made. I think that would give us what
we want; buffers would be queued for flip as soon as they were ready.


> I've looked at the git history and I can only see one present related 
> commit since 1.15.0:
> 60014a4 Replace 'pointer' type with 'void *'
>
> I couldn't see anything in your git repo either.

I found the fix I'd made in January and just sent that out to the list

        [PATCH] present: Queue flips for later execution

> I'm probably missing something so correct me if I'm wrong but it seems 
> that maybe the scheme being used needs reversing. Currently if we get 
> multiple swaps for the same MSC then we only execute the most recent 
> swap when the MSC is met (skipping the preceding swaps). However, this 
> doesn't work in the non-async swap interval 0 case and it only works for 
> none 0 swap intervals because there are only 2 back buffers.

If you're not going to display the later image, you should prevent the
application from wasting time computing it. That's what mesa does when
you set a non-zero vblank_mode, and that works just fine.

> By reversing things, so that if we get multiple swaps for the same MSC 
> then we execute the oldest swap (skipping the later swaps), we're able 
> to properly support the non-async swap interval 0 case.

But it's not useful -- you've computed an image, which is presumably
what the user wants, and then you simply discard it.

If you want vblank_mode=1 behaviour, then you should make your GL
implementation wait until the previous frame has been displayed before
you start drawing the next one. That means needing only one back buffer
for copies and two buffers for flips.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140416/5a57a290/attachment.sig>