On 16/09/16 06:14 PM, Hans de Goede wrote:
> On 16-09-16 10:59, Michel Dänzer wrote:
>> On 16/09/16 05:37 PM, Hans de Goede wrote:
>>> On 16-09-16 08:26, Michel Dänzer wrote:
>>>> On 16/09/16 01:37 PM, Keith Packard wrote:
>>>>> @@ -1943,3 +1948,13 @@ DamageReportDamage(DamagePtr pDamage,
>>>>> RegionPtr pDamageRegion)
>>>>> +DamageFlushDrawable(DrawablePtr pDrawable)
>>>>> + ScreenPtr pScreen = pDrawable->pScreen;
>>>>> + damageScrPriv(pScreen);
>>>>> + if (pScrPriv->funcs.Flush)
>>>>> + (*pScrPriv->funcs.Flush)(pDrawable);
>>>> FWIW, this will do nothing for GPU screens. I'm not sure whether or not
>>>> GPU screens need to be flushed for damage events, what are others'
>>>> thoughts on that?
>>> With render offloading I do think we want to flush,
>> Do you have a specific scenario in mind where a GPU screen needs to be
>> flushed before damage events are sent to a client?
> If a client is somehow tracking a pixmap which gets rendered
> by a secondary GPU, but I did not think about the copy that
> involves, so thinking about this again in that scenario we
> will have:
> 1) Rendering on secondary GPU (aka a GPU screen)
> 2) We need a flush here, but that should already be taken care of
> 3) Copy to buffer/pixmap on primary GPU
> 4) The copy will do damage to the pixmap, but then we're already
> on the primary GPU
>> I've actually almost convinced myself that it's not necessary, because
>> damage events can't refer to any pixmaps directly rendered to by GPU
> See above I think you're right. Following the same logic though
> I do not think the code this patch adds will ever get called on
> a GPU screen, so no need to check for that ?
Right, I merely pointed out that the code in this patch won't do
anything for GPU screens, because I wasn't sure yet if GPU screens need
to be flushed for damage events or not. Sorry if that was confusing.
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
email@example.com: X.Org development