[Mesa-dev] [PATCH 2/2] loader/dri3: Invalidate the drawable after copySubBuffer

Thomas Hellstrom thellstrom at vmware.com
Tue Sep 5 06:50:13 UTC 2017


Hi, Michel,

On 09/05/2017 06:02 AM, Michel Dänzer wrote:
> On 04/09/17 09:27 PM, Thomas Hellstrom wrote:
>> Anyone using copySubBuffer as a replacement for swapBuffers would probably
>> want window resizing to update the viewport.
>>
>> Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
>> ---
>>   src/loader/loader_dri3_helper.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
>> index c0a6e0d..9549b18 100644
>> --- a/src/loader/loader_dri3_helper.c
>> +++ b/src/loader/loader_dri3_helper.c
>> @@ -664,6 +664,8 @@ loader_dri3_copy_sub_buffer(struct loader_dri3_drawable *draw,
>>         dri3_fence_trigger(draw->conn, dri3_fake_front_buffer(draw));
>>         dri3_fence_await(draw->conn, dri3_fake_front_buffer(draw));
>>      }
>> +
>> +   draw->ext->flush->invalidate(draw->dri_drawable);
>>      dri3_fence_await(draw->conn, back);
>>   }
> Your rationale makes some sense to me, but I notice that
> dri2CopySubBuffer doesn't seem to do this. Do you have a test case where
> this makes a difference?
>
>
If you hack glxgears to use copySubBuffer as done in the attached diff, 
you'll see the problem. With dri3 without this patch the window stops 
updating if you resize it.

The bahavior with dri2 is different. If the server doesn't send 
invalidate events (old dri2 server side drivers), then the behavior is, 
as expected, similar to dri3 except rendering continues with an 
incorrect viewport. dri2 with server side events works.

Now dri3 also get server side events on resizing, but the difference 
compared to dri2 is that the dri2 events are processed in _Xreply, so 
they'd automatically get processed when we wait for the server's 
copy_sub_buffer reply, and if there is an invalidate event, we 
invalidate. With dri3 currently we need to explicitly post an 
invalidation to have the code even check for events.

I guess what could perhaps be done is to process any received events in 
dri3_fence_await, and invalidate only if we see a drawable change to try 
to mimic dri2 behaviour..

/Thomas




-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_sub_buffer.diff
Type: text/x-patch
Size: 1438 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170905/11edc655/attachment.bin>


More information about the mesa-dev mailing list