[PATCH xserver 1/2] modesetting: Fix reverse prime partial update issues on secondary GPU outputs

[Michel Dänzer]

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 <hdegoede at 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
>> correctly.
> 
> 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
 returns).

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.


> Also if you look at the screenshot I posted:
> 
> https://fedorapeople.org/~jwrdegoede/IMG_20160915_130555.jpg
> 
> 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.


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