[Mesa-dev] [PATCH 3/3] dri3: Add a synchronisation point for texture-from-pixmap

[Michel Dänzer]

On 02/11/16 04:43 PM, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote:
>> On 02/11/16 04:13 PM, Chris Wilson wrote:
>>> On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
>>>> On 22/10/16 07:00 PM, Chris Wilson wrote:
>>>>> This applies a synchronisation point to GetBuffers() such that binding a
>>>>> texture-from-pixmap its rendering is serialised with X. This matches the
>>>>> synchronisation point inside DRI2, but it is also arguable that implied
>>>>> sync should be explicitly handled by the client by calling glXWaitX()
>>>>> following the binding of all textures. However, currently glXWaitX()
>>>>> only operates on the bound drawable and does not actually flush all
>>>>> Pixmaps associated with the bound context.
>>>>>
>>>>> This fixes an issue (output lag) where the compositor calls glXWaitX()
>>>>> prior to acquiring the damage region from X and binding the
>>>>> texture-from-pixmap.
>>>>
>>>> The X server / driver is responsible for flushing the GPU rendering
>>>> corresponding to damage events before they are sent to clients. The
>>>> modesetting driver is known broken in this regard; are there any other
>>>> setups where this is not happening?
>>>
>>> The issue here is that the serialisation is happening outside of damage
>>> event. Rough timeline:
>>>
>>> client				X
>>>
>>> setup report-on-non-zero damage
>>> 				flush + send damage event 
>>> throttle
>>> start preparing frame		more rendering
>>> query damage region
>>> 				reply with region (no damage event, no flush)
>>
>> Sounds like the X server / driver needs to flush before sending this
>> reply to clients as well.
> 
> With the above, we already have explicit serialisation points in DRI2 -
> we can completely forgo the implicit flush-on-damage.

Are all compositors calling glXWaitX or glXBindTexImageEXT between
receiving damage information and drawing? (Pretty sure the answer is no)

What about compositors not using GLX at all?


I can also think of scenarios where (explicit or implicit) glXWaitX
unnecessarily flushes unrelated GPU work, so I'm not sure it's
necessarily better than the traditional flushing before sending damage
information to clients. Do you have any evidence to support this
paradigm shift?


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