On 16-09-16 09:58, Michel Dänzer wrote:
On 16/09/16 04:18 PM, Hans de Goede wrote:
On 16-09-16 04:00, Michel Dänzer wrote:
On 16/09/16 06:50 AM, Eric Anholt wrote:
Hans de Goede <hdego...@redhat.com> writes:

When using reverse prime we do 2 copies, 1 from the primary GPU's
framebuffer to a shared pixmap and 1 from the shared pixmap to the
secondary GPU's framebuffer.

This means that on the primary GPU side the copy MUST be finished,
before we start the second copy (before the secondary GPU's driver
starts processing the damage on the shared pixmap).

This fixes secondary outputs sometimes showning (some) old fb contents,
because of the 2 copies racing with each other, for an example of
what this looks like see:

Is working around the fact that the primary and secondary aren't
cooperating on dmabuf fencing?  Should they be doing that instead?

Or would glamor_flush be sufficient?

Yes, glamor_flush is sufficient if the kernel drivers handle fences

I will admit that I'm not familiar with all the intrinsics involved here,
but I do not see how glamor_flush would be sufficient.

We must guarantee that the first copy is complete before the second
copy is started. I think that with taking fencing into account this
turns into must make sure the first copy has started, because once
started then the gpu doing the first copy owns the buffer until
it is completed.

But AFAIK flush does not guarantee that the copy has started, only
that it will start real soon now.

Section 2.3.2 of the OpenGL 4.3 specification says:

 Coarse control over command queues is available using the command

        void Flush( void );

 which causes all previously issued GL commands to complete in finite
 time (although such commands may still be executing when Flush

Which to me suggests that the GPU commands should have started executing
when glFlush returns. AFAIK that's the case with all Mesa drivers at least.

Ok, so I just tried to switch to flush() (the proof is in the pudding) that
does seem to fix the race between the 2 copies, but it does not ensure that
the copies happen in the right order! So sometimes I end up with old contents
on the secondary gpu output.

So it looks like we really need glFinish to ensure proper ordering here
(and I've just deleted the v2 of this patchset with flush with I had

Also if you look at the screenshot I posted:


Then you can clearly see that the 2 copies are racing, so it seems
that fencing is not working as it should here.

That's an issue between the OpenGL and kernel drivers.

So all in all I believe that it is best to stick with finish() here,
yes I realize that finish is frowned upon, do note that this only
comes into play when secondary gpu outputs are used.

Still, glFinish is a pretty big hammer, which will block the X server's
main thread until the GPU is finished. And this may happen in each
BlockHandler invocation, which happens quite frequently.

It will only call glFinish if there is actual damage on the
screen pixmap, I know this can still happen a lot, but now a days
most apps limit this to the vblank rate.



xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to