Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 12/01/17 12:09 AM, Cheng, Tony wrote:
> Vblank interrupt fires as soon as the last line of active region is
> scanned out.
> VSync interrupt fires at the vsync.
> VUpdate interrupt fires HW is ready to scan out a new frame, this include
> latch on double buffer registers, starting memory request etc.
> 
> We use VUpdate to accommodate free sync, as in free sync, blank region
> is variable and a frame can be terminate as soon as new surface address
> is written to register.  If we use vblank interrupt will be fired too
> early and might not stretch frame time properly.

What does "fired too early" and "might not stretch frame time properly"
mean exactly?

Is it that the timestamp reported to userspace, which is supposed to
correspond to when scanning out the next frame starts, would be
incorrect? Or something else?


Apart from being too late for some use cases of the
DRM_IOCTL_WAIT_VBLANK ioctl, there's another issue with the VUPDATE
interrupt: Because it's processed after the PFLIP interrupt, the DRM
vblank sequence number is only incremented after a corresponding page
flip completion event is sent to userspace, so the vblank sequence
number in the event is 1 too low.

I'd like to help come up with a solution for this, but I need to
understand the concerns about the VBLANK interrupt vs FreeSync better.


> I think us DAL guys might not have the full understanding of DRM
> vblank machinery.  Is there some document we can go read up on to make
> sure all our assumption is correct?

I'm not sure, but I've been involved with it pretty much since the
beginning, so I can explain some things about it. :)


> From our perspective it seems some of the DRM vblank machinery (or the
> way we implement them) is redundant as our HW can do things that we
> queue off a work item to do automatically if we configure the HW correctly.

Do you mean amdgpu_flip_work_func? I'm not sure how the HW could
automatically wait for fences to signal before executing the flip, but
maybe it could delay the flip until the frame count passes a threshold?
Or are you thinking of something else?


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

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 11/01/17 08:41 PM, Andy Furniss wrote:
> 
> Pure luck noticing this because I haven't tested modesetting driver for
> ages, but -
> 
> These patches also break full screen vdpau playback when using that.
> 
> Result is a screen of mostly junk with a hint of the vid - looks like
> when direct scan out fails on wayland due to tiling mismatch.

Yeah, it's the same effect, due to the scanout buffer using tiling
parameters which aren't supported by the display hardware. In this case,
it happens because the modesetting driver attempts to use page flipping
anyway, and the kernel driver doesn't catch it but pretends that it works.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Harry Wentland]

On 2017-01-11 12:50 AM, Michel Dänzer wrote:

On 10/01/17 09:07 PM, Andy Furniss wrote:

Andy Furniss wrote:


Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.


todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
larger than non DC kernel with powerplay auto. With high it is smaller
but still present.


This particular issue is because DC uses the GPU's VUPDATE interrupt
instead of the VBLANK interrupt to drive the DRM vblank machinery. The
result is that userspace is only notified of a vertical blank period
when it's already over, so it doesn't get a chance to do anything inside
the vertical blank period.




Adding Tony for comment on why DC behaves the way it does.

Harry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Nayan Deshmukh]

On Wed, Jan 11, 2017 at 9:25 PM, Andy Furniss  wrote:
> Nayan Deshmukh wrote:
>>
>> Hi Andy,
>>
>> Can you try this patch? This should help with the tearing.
>
>
> Patch seems to be good - I get page flipping again so DC, modesetting
> and "normal" setup all work OK.
>
Great.

Thanks for the help Michel.

Christian, I will resend the series with the changes. Please review the
other 2
patches.

Regards,
Nayan
>
>>
>> diff --git a/src/gallium/state_trackers/vdpau/output.c
>> b/src/gallium/state_trackers/vdpau/output.c
>> index 48e3133..98a8011 100644
>> --- a/src/gallium/state_trackers/vdpau/output.c
>> +++ b/src/gallium/state_trackers/vdpau/output.c
>> @@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>  res_tmpl.depth0 = 1;
>>  res_tmpl.array_size = 1;
>>  res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
>> -   PIPE_BIND_SHARED;
>> +   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
>>  res_tmpl.usage = PIPE_USAGE_DEFAULT;
>>
>>  pipe_mutex_lock(dev->mutex);
>>
>> Regards,
>> Nayan
>>
>> On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss 
wrote:
>>>
>>> Michel Dänzer wrote:


 On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
>
>
> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer 
> wrote:
>>
>>
>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>>
>>>
>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer 
>>> wrote:


 On 06/01/17 05:50 AM, Andy Furniss wrote:
>
>
> Christian König wrote:
>>
>>
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
>>>
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids extra
>>> copying
>>>
>>> v2: use clip width/height to display a portion of the surface
>>> v3: remove redundant variables, fix wrapping, rename variables
>>>handle vaapi path
>>> v3.1: we need clip_width/height for every frame so we don't need
>>>  to maintain it for each buffer instead use a global
>>> variable
>>> v4: In case of single gpu we can cache the buffers as
>>> applications
>>>use constant number of buffer and we can avoid calls to
>>> present
>>>extension for every frame
>>>
>>> Suggested-by: Leo Liu 
>>> Signed-off-by: Nayan Deshmukh 
>>
>>
>>
>> Acked-by: Christian König .
>>
>> Andy & Leo did you guys already had a chance to test it? To me it
>> looks
>> like this should work now.
>
>
>
> Well there is still the tearing issue from loosing pageflips.
>
> Maybe different GPUs don't see this. I can fix by forcing perf but
> I
> just tested dal and it's not even fixable running that.
>
> I guess that may not count as an issue with these patches as such
> if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.



 Somebody should track down why the buffers sent for presentation in
 this
 case don't use the same tiling parameters as buffers used for GL
via
 DRI3.

>>> I can look into this, but I don't know where to look exactly. Can
you
>>> give some
>>> pointers to get started.
>>
>>
>>
>> Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
>> again, my guess is that it's due to PIPE_BIND_SCANOUT not being set
>> when
>> creating the buffers that are now being directly sent to the X server
>> for presentation.
>>
> So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
> output surfaces of the state tracker. Will introducing
> PIPE_BIND_SCANOUT lead to performance loss for these surfaces?



 Potentially, but I doubt it'll make a big difference for this use case.
 In the future, there might be a feedback mechanism which allows
 re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
 current circumstances, but for now it's probably better to set it (at
 least in cases where we don't know that the buffer can never be scanned
 out directly) to allow for page flipping.
>>>
>>>
>>>
>>> Pure luck noticing this because I haven't tested modesetting driver for
>>> ages, but -
>>>
>>> These patches also break full screen vdpau playback when using that.
>>>
>>> Result is a screen of mostly junk with a hint of the vid - looks like
>>> when direct 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

Can you try this patch? This should help with the tearing.


Patch seems to be good - I get page flipping again so DC, modesetting
and "normal" setup all work OK.



diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 48e3133..98a8011 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 res_tmpl.depth0 = 1;
 res_tmpl.array_size = 1;
 res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_SHARED;
+   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
 res_tmpl.usage = PIPE_USAGE_DEFAULT;

 pipe_mutex_lock(dev->mutex);

Regards,
Nayan

On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss  wrote:

Michel Dänzer wrote:


On 11/01/17 05:13 PM, Nayan Deshmukh wrote:


On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer 
wrote:


On 10/01/17 06:53 PM, Nayan Deshmukh wrote:


On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer 
wrote:


On 06/01/17 05:50 AM, Andy Furniss wrote:


Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
   handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
 to maintain it for each buffer instead use a global
variable
v4: In case of single gpu we can cache the buffers as applications
   use constant number of buffer and we can avoid calls to
present
   extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 



Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it
looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



Somebody should track down why the buffers sent for presentation in
this
case don't use the same tiling parameters as buffers used for GL via
DRI3.


I can look into this, but I don't know where to look exactly. Can you
give some
pointers to get started.



Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
creating the buffers that are now being directly sent to the X server
for presentation.


So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces of the state tracker. Will introducing
PIPE_BIND_SCANOUT lead to performance loss for these surfaces?



Potentially, but I doubt it'll make a big difference for this use case.
In the future, there might be a feedback mechanism which allows
re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
current circumstances, but for now it's probably better to set it (at
least in cases where we don't know that the buffer can never be scanned
out directly) to allow for page flipping.



Pure luck noticing this because I haven't tested modesetting driver for
ages, but -

These patches also break full screen vdpau playback when using that.

Result is a screen of mostly junk with a hint of the vid - looks like
when direct scan out fails on wayland due to tiling mismatch.





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Cheng, Tony]

Vblank interrupt fires as soon as the last line of active region is scanned out.
VSync interrupt fires at the vsync.
VUpdate interrupt fires HW is ready to scan out a new frame, this include latch 
on double buffer registers, starting memory request etc.

We use VUpdate to accommodate free sync, as in free sync, blank region is 
variable and a frame can be terminate as soon as new surface address is written 
to register.  If we use vblank interrupt will be fired too early and might not 
stretch frame time properly.

Dal/dc does not manage any interrupt as dc is architected to behave more like a 
helper.  Dal/amdgpu_dm is the glue code and does interrupt registration and 
handling of interrupt.  I think us DAL guys might not have the full 
understanding of DRM vblank machinery.  Is there some document we can go read 
up on to make sure all our assumption is correct?  From our perspective it 
seems some of the DRM vblank machinery (or the way we implement them) is 
redundant as our HW can do things that we queue off a work item to do 
automatically if we configure the HW correctly.

-Original Message-
From: Wentland, Harry 
Sent: Wednesday, January 11, 2017 9:51 AM
To: Michel Dänzer <mic...@daenzer.net>; Andy Furniss <adf.li...@gmail.com>; 
Nayan Deshmukh <nayan26deshm...@gmail.com>
Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>; Cheng, Tony 
<tony.ch...@amd.com>
Subject: Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back 
buffers(v4)

On 2017-01-11 12:50 AM, Michel Dänzer wrote:
> On 10/01/17 09:07 PM, Andy Furniss wrote:
>> Andy Furniss wrote:
>>
>>> Though recent testing shows this is not true with DAL/DC on 3.7 - 
>>> todo test DC on new drm-next branch.
>>
>> todo done, DC for some reason on both amd-staging-4.7 and 
>> amd-staging-drm-next is "slower" = the tear region is 2 to 3 times 
>> larger than non DC kernel with powerplay auto. With high it is 
>> smaller but still present.
>
> This particular issue is because DC uses the GPU's VUPDATE interrupt 
> instead of the VBLANK interrupt to drive the DRM vblank machinery. The 
> result is that userspace is only notified of a vertical blank period 
> when it's already over, so it doesn't get a chance to do anything 
> inside the vertical blank period.
>
>

Adding Tony for comment on why DC behaves the way it does.

Harry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Nayan Deshmukh]

Hi Andy,

Can you try this patch? This should help with the tearing.

diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 48e3133..98a8011 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -82,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.depth0 = 1;
res_tmpl.array_size = 1;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_SHARED;
+   PIPE_BIND_SHARED | PIPE_BIND_SCANOUT;
res_tmpl.usage = PIPE_USAGE_DEFAULT;

pipe_mutex_lock(dev->mutex);

Regards,
Nayan

On Wed, Jan 11, 2017 at 5:11 PM, Andy Furniss  wrote:
> Michel Dänzer wrote:
>>
>> On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
>>>
>>> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer 
>>> wrote:

 On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>
> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer 
> wrote:
>>
>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>>
>>> Christian König wrote:

 Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>
> dri3 allows us to send handle of a texture directly to X
> so this patch allows a state tracker to directly send its
> texture to X to be used as back buffer and avoids extra
> copying
>
> v2: use clip width/height to display a portion of the surface
> v3: remove redundant variables, fix wrapping, rename variables
>   handle vaapi path
> v3.1: we need clip_width/height for every frame so we don't need
> to maintain it for each buffer instead use a global
> variable
> v4: In case of single gpu we can cache the buffers as applications
>   use constant number of buffer and we can avoid calls to
> present
>   extension for every frame
>
> Suggested-by: Leo Liu 
> Signed-off-by: Nayan Deshmukh 


 Acked-by: Christian König .

 Andy & Leo did you guys already had a chance to test it? To me it
 looks
 like this should work now.
>>>
>>>
>>> Well there is still the tearing issue from loosing pageflips.
>>>
>>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>>> just tested dal and it's not even fixable running that.
>>>
>>> I guess that may not count as an issue with these patches as such if
>>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>>> regression until that happens.
>>
>>
>> Somebody should track down why the buffers sent for presentation in
>> this
>> case don't use the same tiling parameters as buffers used for GL via
>> DRI3.
>>
> I can look into this, but I don't know where to look exactly. Can you
> give some
> pointers to get started.


 Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
 again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
 creating the buffers that are now being directly sent to the X server
 for presentation.

>>> So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
>>> output surfaces of the state tracker. Will introducing
>>> PIPE_BIND_SCANOUT lead to performance loss for these surfaces?
>>
>>
>> Potentially, but I doubt it'll make a big difference for this use case.
>> In the future, there might be a feedback mechanism which allows
>> re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
>> current circumstances, but for now it's probably better to set it (at
>> least in cases where we don't know that the buffer can never be scanned
>> out directly) to allow for page flipping.
>
>
> Pure luck noticing this because I haven't tested modesetting driver for
> ages, but -
>
> These patches also break full screen vdpau playback when using that.
>
> Result is a screen of mostly junk with a hint of the vid - looks like
> when direct scan out fails on wayland due to tiling mismatch.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Michel Dänzer wrote:

On 11/01/17 05:13 PM, Nayan Deshmukh wrote:

On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer  wrote:

On 10/01/17 06:53 PM, Nayan Deshmukh wrote:

On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer  wrote:

On 06/01/17 05:50 AM, Andy Furniss wrote:

Christian König wrote:

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 


Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.


Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.


Somebody should track down why the buffers sent for presentation in this
case don't use the same tiling parameters as buffers used for GL via DRI3.


I can look into this, but I don't know where to look exactly. Can you give some
pointers to get started.


Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
creating the buffers that are now being directly sent to the X server
for presentation.


So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces of the state tracker. Will introducing
PIPE_BIND_SCANOUT lead to performance loss for these surfaces?


Potentially, but I doubt it'll make a big difference for this use case.
In the future, there might be a feedback mechanism which allows
re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
current circumstances, but for now it's probably better to set it (at
least in cases where we don't know that the buffer can never be scanned
out directly) to allow for page flipping.


Pure luck noticing this because I haven't tested modesetting driver for 
ages, but -


These patches also break full screen vdpau playback when using that.

Result is a screen of mostly junk with a hint of the vid - looks like
when direct scan out fails on wayland due to tiling mismatch.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer  wrote:
>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer  wrote:
 On 06/01/17 05:50 AM, Andy Furniss wrote:
> Christian König wrote:
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids extra
>>> copying
>>>
>>> v2: use clip width/height to display a portion of the surface
>>> v3: remove redundant variables, fix wrapping, rename variables
>>>  handle vaapi path
>>> v3.1: we need clip_width/height for every frame so we don't need
>>>to maintain it for each buffer instead use a global variable
>>> v4: In case of single gpu we can cache the buffers as applications
>>>  use constant number of buffer and we can avoid calls to present
>>>  extension for every frame
>>>
>>> Suggested-by: Leo Liu 
>>> Signed-off-by: Nayan Deshmukh 
>>
>> Acked-by: Christian König .
>>
>> Andy & Leo did you guys already had a chance to test it? To me it looks
>> like this should work now.
>
> Well there is still the tearing issue from loosing pageflips.
>
> Maybe different GPUs don't see this. I can fix by forcing perf but I
> just tested dal and it's not even fixable running that.
>
> I guess that may not count as an issue with these patches as such if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.

 Somebody should track down why the buffers sent for presentation in this
 case don't use the same tiling parameters as buffers used for GL via DRI3.

>>> I can look into this, but I don't know where to look exactly. Can you give 
>>> some
>>> pointers to get started.
>>
>> Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
>> again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
>> creating the buffers that are now being directly sent to the X server
>> for presentation.
>>
> So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
> output surfaces of the state tracker. Will introducing
> PIPE_BIND_SCANOUT lead to performance loss for these surfaces?

Potentially, but I doubt it'll make a big difference for this use case.
In the future, there might be a feedback mechanism which allows
re-allocating the buffer with/out PIPE_BIND_SCANOUT according to the
current circumstances, but for now it's probably better to set it (at
least in cases where we don't know that the buffer can never be scanned
out directly) to allow for page flipping.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Nayan Deshmukh]

On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer  wrote:
> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer  wrote:
>>> On 06/01/17 05:50 AM, Andy Furniss wrote:
 Christian König wrote:
> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>> dri3 allows us to send handle of a texture directly to X
>> so this patch allows a state tracker to directly send its
>> texture to X to be used as back buffer and avoids extra
>> copying
>>
>> v2: use clip width/height to display a portion of the surface
>> v3: remove redundant variables, fix wrapping, rename variables
>>  handle vaapi path
>> v3.1: we need clip_width/height for every frame so we don't need
>>to maintain it for each buffer instead use a global variable
>> v4: In case of single gpu we can cache the buffers as applications
>>  use constant number of buffer and we can avoid calls to present
>>  extension for every frame
>>
>> Suggested-by: Leo Liu 
>> Signed-off-by: Nayan Deshmukh 
>
> Acked-by: Christian König .
>
> Andy & Leo did you guys already had a chance to test it? To me it looks
> like this should work now.

 Well there is still the tearing issue from loosing pageflips.

 Maybe different GPUs don't see this. I can fix by forcing perf but I
 just tested dal and it's not even fixable running that.

 I guess that may not count as an issue with these patches as such if
 xorg/xf86-video-amdgpu can work around, but it's a very noticeable
 regression until that happens.
>>>
>>> Somebody should track down why the buffers sent for presentation in this
>>> case don't use the same tiling parameters as buffers used for GL via DRI3.
>>>
>> I can look into this, but I don't know where to look exactly. Can you give 
>> some
>> pointers to get started.
>
> Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
> again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
> creating the buffers that are now being directly sent to the X server
> for presentation.
>
So the only way to avoid this is to have a PIPE_BIND_SCANOUT for the
output surfaces
of the state tracker. Will introducing PIPE_BIND_SCANOUT lead to
performance loss
for these surfaces?

It will probably depend on the way drivers handle PIPE_BIND_SCANOUT.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer  wrote:
>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>> Christian König wrote:
 Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
> dri3 allows us to send handle of a texture directly to X
> so this patch allows a state tracker to directly send its
> texture to X to be used as back buffer and avoids extra
> copying
>
> v2: use clip width/height to display a portion of the surface
> v3: remove redundant variables, fix wrapping, rename variables
>  handle vaapi path
> v3.1: we need clip_width/height for every frame so we don't need
>to maintain it for each buffer instead use a global variable
> v4: In case of single gpu we can cache the buffers as applications
>  use constant number of buffer and we can avoid calls to present
>  extension for every frame
>
> Suggested-by: Leo Liu 
> Signed-off-by: Nayan Deshmukh 

 Acked-by: Christian König .

 Andy & Leo did you guys already had a chance to test it? To me it looks
 like this should work now.
>>>
>>> Well there is still the tearing issue from loosing pageflips.
>>>
>>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>>> just tested dal and it's not even fixable running that.
>>>
>>> I guess that may not count as an issue with these patches as such if
>>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>>> regression until that happens.
>>
>> Somebody should track down why the buffers sent for presentation in this
>> case don't use the same tiling parameters as buffers used for GL via DRI3.
>>
> I can look into this, but I don't know where to look exactly. Can you give 
> some
> pointers to get started.

Looking at src/gallium/auxiliary/vl/vl_winsys_dri3.c and the patches
again, my guess is that it's due to PIPE_BIND_SCANOUT not being set when
creating the buffers that are now being directly sent to the X server
for presentation.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 10/01/17 09:07 PM, Andy Furniss wrote:
> Andy Furniss wrote:
> 
>> Though recent testing shows this is not true with DAL/DC on 3.7 -
>> todo test DC on new drm-next branch.
> 
> todo done, DC for some reason on both amd-staging-4.7 and
> amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
> larger than non DC kernel with powerplay auto. With high it is smaller
> but still present.

This particular issue is because DC uses the GPU's VUPDATE interrupt
instead of the VBLANK interrupt to drive the DRM vblank machinery. The
result is that userspace is only notified of a vertical blank period
when it's already over, so it doesn't get a chance to do anything inside
the vertical blank period.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Alex Deucher]

On Tue, Jan 10, 2017 at 12:56 PM, Andy Furniss  wrote:
> Alex Deucher wrote:
>>
>> On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
>>  wrote:
>>>
>>> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss  wrote:

 Christian König wrote:
>
>
> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>
>>
>> dri3 allows us to send handle of a texture directly to X
>> so this patch allows a state tracker to directly send its
>> texture to X to be used as back buffer and avoids extra
>> copying
>>
>> v2: use clip width/height to display a portion of the surface
>> v3: remove redundant variables, fix wrapping, rename variables
>>   handle vaapi path
>> v3.1: we need clip_width/height for every frame so we don't need
>> to maintain it for each buffer instead use a global variable
>> v4: In case of single gpu we can cache the buffers as applications
>>   use constant number of buffer and we can avoid calls to present
>>   extension for every frame
>>
>> Suggested-by: Leo Liu 
>> Signed-off-by: Nayan Deshmukh 
>
>
>
> Acked-by: Christian König .
>
> Andy & Leo did you guys already had a chance to test it? To me it looks
> like this should work now.



 Well there is still the tearing issue from loosing pageflips.

 Maybe different GPUs don't see this. I can fix by forcing perf but I
 just tested dal and it's not even fixable running that.

 I guess that may not count as an issue with these patches as such if
 xorg/xf86-video-amdgpu can work around, but it's a very noticeable
 regression until that happens.

>>>
>>> That's bad. It should have improved the speed due to less copying
>>> involved.
>>> But it seems there are some problems in the patch. It may be that somehow
>>> we
>>> make calls to present extension on every frame.
>>>
>>
>> This is not the fault of your patches.  They reduce the copying
>> involved with generates less GPU activity which causes the GPU to not
>> ramp up the clocks as high.  For multi-media especially, we really
>> need to add a kernel interface to request a minimum clock floor for
>> specific contexts.
>
>
> Hmm, are these hidden clocks?
>
> echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
>
> With dri2 it's still OK fullscreen, with opengl perf is hurt but it
> doesn't tear fullscreen - just can't make the framerate so player drops
> or slow-mo depending on its settings.
>
> Clearly clocks play a part in that on a non DC kernel high will "fix"
> but even then that's one test at 1080p. I tried 2160p framebuffer and
> it doesn't quite fix that. Going more extreme 4320p it's worse of course
> but full screen dri2 and opengl still won't tear.
>

Thanks for clarifying.  I didn't realize the tearing and performance
were intertwined.

Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Alex Deucher wrote:

On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
 wrote:

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss  wrote:

Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 



Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.



This is not the fault of your patches.  They reduce the copying
involved with generates less GPU activity which causes the GPU to not
ramp up the clocks as high.  For multi-media especially, we really
need to add a kernel interface to request a minimum clock floor for
specific contexts.


Hmm, are these hidden clocks?

echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level

With dri2 it's still OK fullscreen, with opengl perf is hurt but it
doesn't tear fullscreen - just can't make the framerate so player drops
or slow-mo depending on its settings.

Clearly clocks play a part in that on a non DC kernel high will "fix"
but even then that's one test at 1080p. I tried 2160p framebuffer and
it doesn't quite fix that. Going more extreme 4320p it's worse of course
but full screen dri2 and opengl still won't tear.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Alex Deucher]

On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
 wrote:
> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss  wrote:
>> Christian König wrote:
>>>
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

 dri3 allows us to send handle of a texture directly to X
 so this patch allows a state tracker to directly send its
 texture to X to be used as back buffer and avoids extra
 copying

 v2: use clip width/height to display a portion of the surface
 v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
 v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
 v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

 Suggested-by: Leo Liu 
 Signed-off-by: Nayan Deshmukh 
>>>
>>>
>>> Acked-by: Christian König .
>>>
>>> Andy & Leo did you guys already had a chance to test it? To me it looks
>>> like this should work now.
>>
>>
>> Well there is still the tearing issue from loosing pageflips.
>>
>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>> just tested dal and it's not even fixable running that.
>>
>> I guess that may not count as an issue with these patches as such if
>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>> regression until that happens.
>>
>
> That's bad. It should have improved the speed due to less copying involved.
> But it seems there are some problems in the patch. It may be that somehow we
> make calls to present extension on every frame.
>

This is not the fault of your patches.  They reduce the copying
involved with generates less GPU activity which causes the GPU to not
ramp up the clocks as high.  For multi-media especially, we really
need to add a kernel interface to request a minimum clock floor for
specific contexts.

Alex

> Andy you are using dri3 for testing, right?
>
> Leo, did you also experience tearing issues?
>
> Regards,
> Nayan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Andy Furniss wrote:


Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.


todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
larger than non DC kernel with powerplay auto. With high it is smaller
but still present.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Nayan Deshmukh wrote:

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss  wrote:

Christian König wrote:


Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:


dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 



Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.



Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.



That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.


Tiling issue that Michel suggested?

FWIW in windowed playback everything (dri2/3/opengl) has this, I assume
because I don't get pageflipping then. I wouldn't notice though because
even if the player opens the window at the top of the screen, the window
border makes the vid low enough to miss the tear.
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.


Andy you are using dri3 for testing, right?


Yes, there is no (fullscreen) tearing if I startx with DRI3 disabled.


Leo, did you also experience tearing issues?


It's quite possible that most won't see this -

I use a non-compositing desktop (fluxbox), so I guess unless people use
unredirect full screen windows they may still get gl page flipping?

It's only the top of the screen and you won't notice on many video
unless there is a lot of horizontal panning.


Regards,
Nayan



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Nayan Deshmukh]

On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer  wrote:
> On 06/01/17 05:50 AM, Andy Furniss wrote:
>> Christian König wrote:
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
 dri3 allows us to send handle of a texture directly to X
 so this patch allows a state tracker to directly send its
 texture to X to be used as back buffer and avoids extra
 copying

 v2: use clip width/height to display a portion of the surface
 v3: remove redundant variables, fix wrapping, rename variables
  handle vaapi path
 v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
 v4: In case of single gpu we can cache the buffers as applications
  use constant number of buffer and we can avoid calls to present
  extension for every frame

 Suggested-by: Leo Liu 
 Signed-off-by: Nayan Deshmukh 
>>>
>>> Acked-by: Christian König .
>>>
>>> Andy & Leo did you guys already had a chance to test it? To me it looks
>>> like this should work now.
>>
>> Well there is still the tearing issue from loosing pageflips.
>>
>> Maybe different GPUs don't see this. I can fix by forcing perf but I
>> just tested dal and it's not even fixable running that.
>>
>> I guess that may not count as an issue with these patches as such if
>> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
>> regression until that happens.
>
> Somebody should track down why the buffers sent for presentation in this
> case don't use the same tiling parameters as buffers used for GL via DRI3.
>
I can look into this, but I don't know where to look exactly. Can you give some
pointers to get started.

Regards,
Nayan
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Nayan Deshmukh]

On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss  wrote:
> Christian König wrote:
>>
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids extra
>>> copying
>>>
>>> v2: use clip width/height to display a portion of the surface
>>> v3: remove redundant variables, fix wrapping, rename variables
>>>  handle vaapi path
>>> v3.1: we need clip_width/height for every frame so we don't need
>>>to maintain it for each buffer instead use a global variable
>>> v4: In case of single gpu we can cache the buffers as applications
>>>  use constant number of buffer and we can avoid calls to present
>>>  extension for every frame
>>>
>>> Suggested-by: Leo Liu 
>>> Signed-off-by: Nayan Deshmukh 
>>
>>
>> Acked-by: Christian König .
>>
>> Andy & Leo did you guys already had a chance to test it? To me it looks
>> like this should work now.
>
>
> Well there is still the tearing issue from loosing pageflips.
>
> Maybe different GPUs don't see this. I can fix by forcing perf but I
> just tested dal and it's not even fixable running that.
>
> I guess that may not count as an issue with these patches as such if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.
>

That's bad. It should have improved the speed due to less copying involved.
But it seems there are some problems in the patch. It may be that somehow we
make calls to present extension on every frame.

Andy you are using dri3 for testing, right?

Leo, did you also experience tearing issues?

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Michel Dänzer]

On 06/01/17 05:50 AM, Andy Furniss wrote:
> Christian König wrote:
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to be used as back buffer and avoids extra
>>> copying
>>>
>>> v2: use clip width/height to display a portion of the surface
>>> v3: remove redundant variables, fix wrapping, rename variables
>>>  handle vaapi path
>>> v3.1: we need clip_width/height for every frame so we don't need
>>>to maintain it for each buffer instead use a global variable
>>> v4: In case of single gpu we can cache the buffers as applications
>>>  use constant number of buffer and we can avoid calls to present
>>>  extension for every frame
>>>
>>> Suggested-by: Leo Liu 
>>> Signed-off-by: Nayan Deshmukh 
>>
>> Acked-by: Christian König .
>>
>> Andy & Leo did you guys already had a chance to test it? To me it looks
>> like this should work now.
> 
> Well there is still the tearing issue from loosing pageflips.
> 
> Maybe different GPUs don't see this. I can fix by forcing perf but I
> just tested dal and it's not even fixable running that.
> 
> I guess that may not count as an issue with these patches as such if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.

Somebody should track down why the buffers sent for presentation in this
case don't use the same tiling parameters as buffers used for GL via DRI3.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Andy Furniss]

Christian König wrote:

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
 handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
   to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
 use constant number of buffer and we can avoid calls to present
 extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 


Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks
like this should work now.


Well there is still the tearing issue from loosing pageflips.

Maybe different GPUs don't see this. I can fix by forcing perf but I
just tested dal and it's not even fixable running that.

I guess that may not count as an issue with these patches as such if
xorg/xf86-video-amdgpu can work around, but it's a very noticeable
regression until that happens.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Leo Liu]

On 01/05/2017 05:21 AM, Christian König wrote:

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
 handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
   to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
 use constant number of buffer and we can avoid calls to present
 extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 


Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it 
looks like this should work now.


Nayan and I worked offline for this last couple of weeks, the patch set 
has been tested.


This patch is
Reviewed-by: Leo Liu 

Regards,
Leo



If in need I can setup a test system as well.

Regards,
Christian.


---
  configure.ac  |   2 +-
  src/gallium/auxiliary/vl/vl_winsys.h  |   5 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 126 
++

  3 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/configure.ac b/configure.ac
index 799f5eb..94aac34 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2078,7 +2078,7 @@ if test "x$enable_xvmc" = xyes -o \
  "x$enable_va" = xyes; then
  if test x"$enable_dri3" = xyes; then
  PKG_CHECK_MODULES([VL], [xcb-dri3 xcb-present xcb-sync 
xshmfence >= $XSHMFENCE_REQUIRED
- x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])
+ xcb-xfixes x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])

  else
  PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])

  fi
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h

index 26db9f2..e1f9b27 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,11 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  +   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen,
+   struct pipe_resource *buffer,
+   uint32_t width, uint32_t height);
+
 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c

index 2929928..a810dea 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
#include "loader.h"
  @@ -71,9 +72,12 @@ struct vl_dri3_screen
 xcb_special_event_t *special_event;
   struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t clip_width, clip_height;
   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
 int cur_back;
+   int next_back;
   struct u_rect dirty_areas[BACK_BUFFER_NUM];
  @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!scrn->output_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,29 +241,31 @@ dri3_alloc_back_buffer(struct vl_dri3_screen 
*scrn)

 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   templ.width0 = (scrn->output_texture) ?
+  scrn->output_texture->width0 : scrn->width;
+   templ.height0 = (scrn->output_texture) ?
+   scrn->output_texture->height0 : scrn->height;
 templ.depth0 = 1;
 templ.array_size = 1;
   if (scrn->is_different_gpu) {
-  buffer->texture = 
scrn->base.pscreen->resource_create(scrn->base.pscreen,

- );
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+ scrn->base.pscreen->resource_create(scrn->base.pscreen, );
if (!buffer->texture)
   goto unmap_shm;
  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
  PIPE_BIND_LINEAR;
-  buffer->linear_texture = 
scrn->base.pscreen->resource_create(scrn->base.pscreen,

- );
+  buffer->linear_texture =
+ scrn->base.pscreen->resource_create(scrn->base.pscreen, );
pixmap_buffer_texture = buffer->linear_texture;
  if 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Christian König]

Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
 handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
   to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
 use constant number of buffer and we can avoid calls to present
 extension for every frame

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 


Acked-by: Christian König .

Andy & Leo did you guys already had a chance to test it? To me it looks 
like this should work now.


If in need I can setup a test system as well.

Regards,
Christian.


---
  configure.ac  |   2 +-
  src/gallium/auxiliary/vl/vl_winsys.h  |   5 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 126 ++
  3 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/configure.ac b/configure.ac
index 799f5eb..94aac34 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2078,7 +2078,7 @@ if test "x$enable_xvmc" = xyes -o \
  "x$enable_va" = xyes; then
  if test x"$enable_dri3" = xyes; then
  PKG_CHECK_MODULES([VL], [xcb-dri3 xcb-present xcb-sync xshmfence >= 
$XSHMFENCE_REQUIRED
- x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
+ xcb-xfixes x11-xcb xcb xcb-dri2 >= 
$XCBDRI2_REQUIRED])
  else
  PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
  fi
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..e1f9b27 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,11 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  
+   void

+   (*set_back_texture_from_output)(struct vl_screen *vscreen,
+   struct pipe_resource *buffer,
+   uint32_t width, uint32_t height);
+
 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..a810dea 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "loader.h"
  
@@ -71,9 +72,12 @@ struct vl_dri3_screen

 xcb_special_event_t *special_event;
  
 struct pipe_context *pipe;

+   struct pipe_resource *output_texture;
+   uint32_t clip_width, clip_height;
  
 struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];

 int cur_back;
+   int next_back;
  
 struct u_rect dirty_areas[BACK_BUFFER_NUM];
  
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,

 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!scrn->output_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,29 +241,31 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   templ.width0 = (scrn->output_texture) ?
+  scrn->output_texture->width0 : scrn->width;
+   templ.height0 = (scrn->output_texture) ?
+   scrn->output_texture->height0 : scrn->height;
 templ.depth0 = 1;
 templ.array_size = 1;
  
 if (scrn->is_different_gpu) {

-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen, 
);
if (!buffer->texture)
   goto unmap_shm;
  
templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |

  PIPE_BIND_LINEAR;
-  buffer->linear_texture = 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
-  );
+  buffer->linear_texture =
+  scrn->base.pscreen->resource_create(scrn->base.pscreen, );
pixmap_buffer_texture = buffer->linear_texture;
  
if (!buffer->linear_texture)

   goto 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v2)

[Leo Liu]

On 11/04/2016 01:24 PM, Nayan Deshmukh wrote:

On Fri, Nov 04, 2016 at 12:20:51PM -0400, Leo Liu wrote:

Hi Nayan,

With this patch, the resizing corruption is fixed, thanks for that.

Still a few comments below.


On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 
---
   src/gallium/auxiliary/vl/vl_winsys.h  |   4 ++
   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 109 
++
   2 files changed, 99 insertions(+), 14 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908e9c6 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
  void *
  (*get_private)(struct vl_screen *vscreen);
+   void
+   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
pipe_resource *buffer,
+ uint32_t width, uint32_t height);
+
  struct pipe_screen *pscreen;
  struct pipe_loader_device *dev;
   };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..9739be4 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
   #include 
   #include 
   #include 
+#include 
   #include "loader.h"
@@ -56,7 +57,9 @@ struct vl_dri3_buffer
  struct xshmfence *shm_fence;
  bool busy;
+   bool is_external_texture;
  uint32_t width, height, pitch;
+   uint32_t clip_width, clip_height;
   };
   struct vl_dri3_screen
@@ -71,6 +74,9 @@ struct vl_dri3_screen
  xcb_special_event_t *special_event;
  struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;

Are these clipping sizes?

Yes indeed, may be something like output_texture_clip_width would be more 
appropriate


I think the clipping size is nothing to do with the output texture size.

Is it possible just combine it with below and make it simple.

+   uint32_t clip_width, clip_height;



  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
  int cur_back;
@@ -105,7 +111,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
  xcb_free_pixmap(scrn->conn, buffer->pixmap);
  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
  xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
  if (buffer->linear_texture)
  pipe_resource_reference(>linear_texture, NULL);
  FREE(buffer);
@@ -236,14 +243,23 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
  templ.target = PIPE_TEXTURE_2D;
  templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  buffer->clip_width = (scrn->output_texture_width) ? scrn->output_texture_width 
: scrn->output_texture->width0;
+  buffer->clip_height = (scrn->output_texture_height) ? 
scrn->output_texture_height : scrn->output_texture->height0;

Can you wrap these lines and many new added lines below?
Normally make a line less than ~80 chars, and make lines from above and
below balanced.
I think the whole purpose of this is to make more readable and looks nicer.


buffer->clip_width = (scrn->output_texture_width) ? 
scrn->output_texture_width
 : scrn->output_texture->width0;

Is something like this fine?


I think looks better if move the ":' up, or maybe 3 lines.
Please fix the same way for the similar long lines below.

Regards,
Leo



+  templ.width0 = scrn->output_texture->width0;
+  templ.height0 = scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   buffer->clip_width = scrn->width;
+   buffer->clip_height = scrn->height;
+   }
  templ.depth0 = 1;
  templ.array_size = 1;
  if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+   
 );
 if (!buffer->texture)
goto unmap_shm;
@@ -257,8 +273,8 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
goto no_linear_texture;
  } else {
 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v2)

[Nayan Deshmukh]

On Fri, Nov 04, 2016 at 12:20:51PM -0400, Leo Liu wrote:
> Hi Nayan,
> 
> With this patch, the resizing corruption is fixed, thanks for that.
> 
> Still a few comments below.
> 
> 
> On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:
> > dri3 allows us to send handle of a texture directly to X
> > so this patch allows a state tracker to directly send its
> > texture to X to be used as back buffer and avoids extra
> > copying
> > 
> > v2: use clip width/height to display a portion of the surface
> > 
> > Suggested-by: Leo Liu 
> > Signed-off-by: Nayan Deshmukh 
> > ---
> >   src/gallium/auxiliary/vl/vl_winsys.h  |   4 ++
> >   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 109 
> > ++
> >   2 files changed, 99 insertions(+), 14 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> > b/src/gallium/auxiliary/vl/vl_winsys.h
> > index 26db9f2..908e9c6 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > @@ -59,6 +59,10 @@ struct vl_screen
> >  void *
> >  (*get_private)(struct vl_screen *vscreen);
> > +   void
> > +   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
> > pipe_resource *buffer,
> > + uint32_t width, uint32_t height);
> > +
> >  struct pipe_screen *pscreen;
> >  struct pipe_loader_device *dev;
> >   };
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> > b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > index 2929928..9739be4 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > @@ -31,6 +31,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include "loader.h"
> > @@ -56,7 +57,9 @@ struct vl_dri3_buffer
> >  struct xshmfence *shm_fence;
> >  bool busy;
> > +   bool is_external_texture;
> >  uint32_t width, height, pitch;
> > +   uint32_t clip_width, clip_height;
> >   };
> >   struct vl_dri3_screen
> > @@ -71,6 +74,9 @@ struct vl_dri3_screen
> >  xcb_special_event_t *special_event;
> >  struct pipe_context *pipe;
> > +   struct pipe_resource *output_texture;
> > +   uint32_t output_texture_width;
> > +   uint32_t output_texture_height;
> 
> Are these clipping sizes?
Yes indeed, may be something like output_texture_clip_width would be more 
appropriate
> 
> >  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> >  int cur_back;
> > @@ -105,7 +111,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> >  xcb_free_pixmap(scrn->conn, buffer->pixmap);
> >  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> >  xshmfence_unmap_shm(buffer->shm_fence);
> > -   pipe_resource_reference(>texture, NULL);
> > +   if (!buffer->is_external_texture)
> > +  pipe_resource_reference(>texture, NULL);
> >  if (buffer->linear_texture)
> >  pipe_resource_reference(>linear_texture, NULL);
> >  FREE(buffer);
> > @@ -236,14 +243,23 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> >  templ.target = PIPE_TEXTURE_2D;
> >  templ.last_level = 0;
> > -   templ.width0 = scrn->width;
> > -   templ.height0 = scrn->height;
> > +   if (scrn->output_texture) {
> > +  buffer->clip_width = (scrn->output_texture_width) ? 
> > scrn->output_texture_width : scrn->output_texture->width0;
> > +  buffer->clip_height = (scrn->output_texture_height) ? 
> > scrn->output_texture_height : scrn->output_texture->height0;
> 
> Can you wrap these lines and many new added lines below?
> Normally make a line less than ~80 chars, and make lines from above and
> below balanced.
> I think the whole purpose of this is to make more readable and looks nicer.
> 
buffer->clip_width = (scrn->output_texture_width) ? 
scrn->output_texture_width
 : scrn->output_texture->width0;

Is something like this fine?
> > +  templ.width0 = scrn->output_texture->width0;
> > +  templ.height0 = scrn->output_texture->height0;
> > +   } else {
> > +   templ.width0 = scrn->width;
> > +   templ.height0 = scrn->height;
> > +   buffer->clip_width = scrn->width;
> > +   buffer->clip_height = scrn->height;
> > +   }
> >  templ.depth0 = 1;
> >  templ.array_size = 1;
> >  if (scrn->is_different_gpu) {
> > -  buffer->texture = 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > -);
> > +  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > +   
> >  );
> > if (!buffer->texture)
> >goto unmap_shm;
> > @@ -257,8 +273,8 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >goto 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v2)

[Leo Liu]

Hi Nayan,

With this patch, the resizing corruption is fixed, thanks for that.

Still a few comments below.


On 11/04/2016 03:08 AM, Nayan Deshmukh wrote:

dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying

v2: use clip width/height to display a portion of the surface

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/vl/vl_winsys.h  |   4 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 109 ++
  2 files changed, 99 insertions(+), 14 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908e9c6 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  
+   void

+   (*set_back_texture_from_output)(struct vl_screen *vscreen, struct 
pipe_resource *buffer,
+ uint32_t width, uint32_t height);
+
 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..9739be4 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "loader.h"
  
@@ -56,7 +57,9 @@ struct vl_dri3_buffer

 struct xshmfence *shm_fence;
  
 bool busy;

+   bool is_external_texture;
 uint32_t width, height, pitch;
+   uint32_t clip_width, clip_height;
  };
  
  struct vl_dri3_screen

@@ -71,6 +74,9 @@ struct vl_dri3_screen
 xcb_special_event_t *special_event;
  
 struct pipe_context *pipe;

+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;


Are these clipping sizes?

  
 struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];

 int cur_back;
@@ -105,7 +111,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,14 +243,23 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  buffer->clip_width = (scrn->output_texture_width) ? scrn->output_texture_width 
: scrn->output_texture->width0;
+  buffer->clip_height = (scrn->output_texture_height) ? 
scrn->output_texture_height : scrn->output_texture->height0;


Can you wrap these lines and many new added lines below?
Normally make a line less than ~80 chars, and make lines from above and 
below balanced.

I think the whole purpose of this is to make more readable and looks nicer.


+  templ.width0 = scrn->output_texture->width0;
+  templ.height0 = scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   buffer->clip_width = scrn->width;
+   buffer->clip_height = scrn->height;
+   }
 templ.depth0 = 1;
 templ.array_size = 1;
  
 if (scrn->is_different_gpu) {

-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+   
 );
if (!buffer->texture)
   goto unmap_shm;
  
@@ -257,8 +273,8 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)

   goto no_linear_texture;
 } else {
templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
-);
+  buffer->texture = (scrn->output_texture) ? scrn->output_texture : 
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+   
 );
if (!buffer->texture)
   goto unmap_shm;
pixmap_buffer_texture = buffer->texture;
@@ -271,11 +287,15 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 usage);
 buffer_fd = 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

Regarding to xcb_present_pixmap client call, you might have to check 
xserver present/present.c on how xserver deal with it.


Regards,
Leo

On 11/02/2016 10:55 AM, Nayan Deshmukh wrote:

Hi Leo,

To support clipping of the output texture I was trying to send a 
xcb_xfixes_region as the fifth argument (i.e valid-area) to
xcb_present_pixmap but it still displays the entire surface. Am I 
missing something?


Regards,
Nayan



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

Hi Leo,

To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth argument (i.e valid-area) to
xcb_present_pixmap but it still displays the entire surface. Am I missing
something?

Regards,
Nayan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:

On 28/10/16 08:19 PM, Andy Furniss wrote:

Michel Dänzer wrote:

On 27/10/16 07:52 PM, Andy Furniss wrote:

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.

Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.


It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
doesn't finish within the vertical blank period.


Yea, I didn't word that very well, and also didn't say res (1080p)
making it even less useful.

Naive question = does the blit have to be "backwards", seems I wouldn't
notice if it were the same way as scanout?


It's not backwards. The problem is that OpenGL doesn't provide a
rectangle primitive, so glamor's blits end up being rendered as two
triangles. In order to avoid tearing, at least the first triangle needs
to finish rendering within the vertical blank period.


OK, so with a meaner test like doing -

xrandr --output DVI-D-0  --fb 3840x2160 --panning 3840x2160

and scrolling top left I can get a larger tear area and can see that
the triangles are split top left to bottom right. Possibly misleading
trying to judge what's happening visually, but it looks like the lower
/left triangle is rendered first with the one that covers most of the
top of the screen being the "late" one. If that's correct and assuming
they are copied top to bottom, then maybe there would be much less
visible disturbance if it were the other way round.


I guess I am being far too simplistic here, not knowing even the most
basic detail, like what format is the actual framebuffer that gets
scanned out really kept in?

I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
leads to another thought/question. Currently to record screen with VCE
is quite bottle necked by copy to ram/convert to nv12 and copy back.

Are there any show stopping issues that would preclude avoiding the
copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?


Not that I know of. E.g. something like this could work:

With a GLX context using the X root window as the readable, use
glReadPixels to store the screen contents in a PBO, then continue
processing as necessary from there.


Thanks, that's good to know.


Longer term I have an idea how to make the DDX driver support page
flipping in this case as well, but in the meantime making the buffers
sent for presentation tiled instead of linear should allow page flipping
to be used. https://patchwork.freedesktop.org/patch/110569/ might be
enough, which seems to be the best candidate to resolve the nouveau
VDPAU issues as well.


Doesn't help (one quick test with ddx patch).


Weird, not sure why the buffer tiling doesn't match that of the X screen
pixmap then.


I re-tested just in case I messed up, but still can't get it to
work/help.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Michel Dänzer]

On 28/10/16 08:19 PM, Andy Furniss wrote:
> Michel Dänzer wrote:
>> On 27/10/16 07:52 PM, Andy Furniss wrote:
>>> Andy Furniss wrote:
 Michel Dänzer wrote:
> On 26/10/16 08:07 PM, Andy Furniss wrote:
>>
>> The bad = Starting with DRI3 (which is default) I still get trashed
>> rendering full screen. Windowed including re-sizing seems OK.
>>
>> I use Fluxbox window manager, which does not use compositing -
>> IIRC this has historically shown some ddx DRI2/3 issue that wasn't
>> visible to those testing with compositing (but then the full screen
>> case may avoid compositing anyway depending on settings).
>
> You may be running into a DDX driver issue fixed by
> https://patchwork.freedesktop.org/patch/118514/ .

 Yes, that was it, OK with that patch.
>>>
>>> Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
>>> fails top 5% of screen unless I force GPU perf high.
>>>
>>> Not related to this patch directly of course, but I am a bit surprised
>>> that on auto powerplay the tonga is too slow to make 60Hz.
>>
>> It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
>> doesn't finish within the vertical blank period.
> 
> Yea, I didn't word that very well, and also didn't say res (1080p)
> making it even less useful.
> 
> Naive question = does the blit have to be "backwards", seems I wouldn't
> notice if it were the same way as scanout?

It's not backwards. The problem is that OpenGL doesn't provide a
rectangle primitive, so glamor's blits end up being rendered as two
triangles. In order to avoid tearing, at least the first triangle needs
to finish rendering within the vertical blank period.


> I guess I am being far too simplistic here, not knowing even the most
> basic detail, like what format is the actual framebuffer that gets
> scanned out really kept in?
> 
> I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
> leads to another thought/question. Currently to record screen with VCE
> is quite bottle necked by copy to ram/convert to nv12 and copy back.
> 
> Are there any show stopping issues that would preclude avoiding the
> copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?

Not that I know of. E.g. something like this could work:

With a GLX context using the X root window as the readable, use
glReadPixels to store the screen contents in a PBO, then continue
processing as necessary from there.


>> Longer term I have an idea how to make the DDX driver support page
>> flipping in this case as well, but in the meantime making the buffers
>> sent for presentation tiled instead of linear should allow page flipping
>> to be used. https://patchwork.freedesktop.org/patch/110569/ might be
>> enough, which seems to be the best candidate to resolve the nouveau
>> VDPAU issues as well.
> 
> Doesn't help (one quick test with ddx patch).

Weird, not sure why the buffer tiling doesn't match that of the X screen
pixmap then.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:

On 27/10/16 07:52 PM, Andy Furniss wrote:

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.

Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.


It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
doesn't finish within the vertical blank period.


Yea, I didn't word that very well, and also didn't say res (1080p)
making it even less useful.

Naive question = does the blit have to be "backwards", seems I wouldn't
notice if it were the same way as scanout?

I guess I am being far too simplistic here, not knowing even the most
basic detail, like what format is the actual framebuffer that gets
scanned out really kept in?

I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
leads to another thought/question. Currently to record screen with VCE
is quite bottle necked by copy to ram/convert to nv12 and copy back.

Are there any show stopping issues that would preclude avoiding the
copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?


Longer term I have an idea how to make the DDX driver support page
flipping in this case as well, but in the meantime making the buffers
sent for presentation tiled instead of linear should allow page flipping
to be used. https://patchwork.freedesktop.org/patch/110569/ might be
enough, which seems to be the best candidate to resolve the nouveau
VDPAU issues as well.


Doesn't help (one quick test with ddx patch).


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Michel Dänzer]

On 27/10/16 07:52 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>> Michel Dänzer wrote:
>>> On 26/10/16 08:07 PM, Andy Furniss wrote:

 The bad = Starting with DRI3 (which is default) I still get trashed
 rendering full screen. Windowed including re-sizing seems OK.

 I use Fluxbox window manager, which does not use compositing -
 IIRC this has historically shown some ddx DRI2/3 issue that wasn't
 visible to those testing with compositing (but then the full screen
 case may avoid compositing anyway depending on settings).
>>>
>>> You may be running into a DDX driver issue fixed by
>>> https://patchwork.freedesktop.org/patch/118514/ .
>>
>> Yes, that was it, OK with that patch.
> 
> Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
> fails top 5% of screen unless I force GPU perf high.
> 
> Not related to this patch directly of course, but I am a bit surprised
> that on auto powerplay the tonga is too slow to make 60Hz.

It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
doesn't finish within the vertical blank period.

Longer term I have an idea how to make the DDX driver support page
flipping in this case as well, but in the meantime making the buffers
sent for presentation tiled instead of linear should allow page flipping
to be used. https://patchwork.freedesktop.org/patch/110569/ might be
enough, which seems to be the best candidate to resolve the nouveau
VDPAU issues as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Thu, Oct 27, 2016 at 11:07 PM, Leo Liu  wrote:

>
>
> On 10/27/2016 01:20 PM, Nayan Deshmukh wrote:
>
>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu  wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>>

 On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:

> Suggested-by: Leo Liu < leo@amd.com>
> Signed-off-by: Nayan Deshmukh < 
> nayan26deshm...@gmail.com>
> ---
>src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
> +++
>2 files changed, 83 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 26db9f2..7c56b48 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -59,6 +59,10 @@ struct vl_screen
>   void *
>   (*get_private)(struct vl_screen *vscreen);
> +   void
> +   (*set_output_texture)(struct vl_screen *vscreen, struct
> pipe_resource *buffer,
> + uint32_t width, uint32_t height);
> +
>
 I think it's more appropriate if it's called
 "set_back_texture_from_output"

>>> Yeah that makes more sense.
>>>
   struct pipe_screen *pscreen;
>   struct pipe_loader_device *dev;
>};
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 2929928..44d6f4c 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>   struct xshmfence *shm_fence;
>   bool busy;
> +   bool is_external_texture;
>   uint32_t width, height, pitch;
>};
> @@ -71,6 +72,9 @@ struct vl_dri3_screen
>   xcb_special_event_t *special_event;
>   struct pipe_context *pipe;
> +   struct pipe_resource *output_texture;
> +   uint32_t output_texture_width;
> +   uint32_t output_texture_height;
>   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>   int cur_back;
> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>   xcb_free_pixmap(scrn->conn, buffer->pixmap);
>   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>   xshmfence_unmap_shm(buffer->shm_fence);
> -   pipe_resource_reference(>texture, NULL);
> +   if (!buffer->is_external_texture)
> +  pipe_resource_reference(>texture, NULL);
>   if (buffer->linear_texture)
>   pipe_resource_reference(>linear_texture, NULL);
>   FREE(buffer);
> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
> *scrn)
>   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>   templ.target = PIPE_TEXTURE_2D;
>   templ.last_level = 0;
> -   templ.width0 = scrn->width;
> -   templ.height0 = scrn->height;
> +   if (scrn->output_texture) {
> +  templ.width0 = (scrn->output_texture_width) ?
> + scrn->output_texture_width :
> + scrn->output_texture->width0;
> +  templ.height0 = (scrn->output_texture_height) ?
> +  scrn->output_texture_height :
> +  scrn->output_texture->height0;
> +   } else {
> +   templ.width0 = scrn->width;
> +   templ.height0 = scrn->height;
> +   }
>   templ.depth0 = 1;
>   templ.array_size = 1;
>   if (scrn->is_different_gpu) {
> -  buffer->texture = scrn->base.pscreen->resource_c
> reate(scrn->base.pscreen,
> +  buffer->texture = (scrn->output_texture) ?
> +scrn->output_texture :
> +scrn->base.pscreen->resource_c
> reate(scrn->base.pscreen,
>);
>
 Why not just make it in the same line?

 I was just trying to limit characters to 78 as given in mesa coding
>>> style.
>>>
>>
>> It's really matters if just over a few chars. which way do you think it
>> will look better?
>>
>>
>> I would prefer it in a single line, anyways I just checked that it used
> in single line in entire
> vl code.
>
>>
>>>  if (!buffer->texture)
> goto unmap_shm;
> @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> goto no_linear_texture;
>   } else {
>  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> -  buffer->texture = scrn->base.pscreen->resource_c
> reate(scrn->base.pscreen,
> +  buffer->texture = (scrn->output_texture) ?
> +

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

On 10/27/2016 01:20 PM, Nayan Deshmukh wrote:



On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu > wrote:




On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:

On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:


On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:

Suggested-by: Leo Liu >
Signed-off-by: Nayan Deshmukh
>
---
   src/gallium/auxiliary/vl/vl_winsys.h   |  4 ++
   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
+++
   2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..7c56b48 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
  void *
  (*get_private)(struct vl_screen *vscreen);
+   void
+   (*set_output_texture)(struct vl_screen *vscreen,
struct pipe_resource *buffer,
+ uint32_t width, uint32_t
height);
+

I think it's more appropriate if it's called
"set_back_texture_from_output"

Yeah that makes more sense.

  struct pipe_screen *pscreen;
  struct pipe_loader_device *dev;
   };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..44d6f4c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -56,6 +56,7 @@ struct vl_dri3_buffer
  struct xshmfence *shm_fence;
  bool busy;
+   bool is_external_texture;
  uint32_t width, height, pitch;
   };
@@ -71,6 +72,9 @@ struct vl_dri3_screen
  xcb_special_event_t *special_event;
  struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
  struct vl_dri3_buffer
*back_buffers[BACK_BUFFER_NUM];
  int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct
vl_dri3_screen *scrn,
  xcb_free_pixmap(scrn->conn, buffer->pixmap);
  xcb_sync_destroy_fence(scrn->conn,
buffer->sync_fence);
  xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
  if (buffer->linear_texture)
 
pipe_resource_reference(>linear_texture, NULL);

  FREE(buffer);
@@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct
vl_dri3_screen *scrn)
  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
  templ.target = PIPE_TEXTURE_2D;
  templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  templ.width0 = (scrn->output_texture_width) ?
+  scrn->output_texture_width :
+  scrn->output_texture->width0;
+  templ.height0 = (scrn->output_texture_height) ?
+ scrn->output_texture_height :
+ scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   }
  templ.depth0 = 1;
  templ.array_size = 1;
  if (scrn->is_different_gpu) {
-  buffer->texture =
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+ scrn->base.pscreen->resource_create(scrn->base.pscreen,
   );

Why not just make it in the same line?

I was just trying to limit characters to 78 as given in mesa
  

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Thu, Oct 27, 2016 at 10:50 PM, Nayan Deshmukh 
wrote:

>
>
> On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu  wrote:
>
>>
>>
>> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>>

 On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:

> Suggested-by: Leo Liu 
> Signed-off-by: Nayan Deshmukh 
> ---
>src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
> +++
>2 files changed, 83 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 26db9f2..7c56b48 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -59,6 +59,10 @@ struct vl_screen
>   void *
>   (*get_private)(struct vl_screen *vscreen);
> +   void
> +   (*set_output_texture)(struct vl_screen *vscreen, struct
> pipe_resource *buffer,
> + uint32_t width, uint32_t height);
> +
>
 I think it's more appropriate if it's called
 "set_back_texture_from_output"

>>> Yeah that makes more sense.
>>>
   struct pipe_screen *pscreen;
>   struct pipe_loader_device *dev;
>};
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 2929928..44d6f4c 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>   struct xshmfence *shm_fence;
>   bool busy;
> +   bool is_external_texture;
>   uint32_t width, height, pitch;
>};
> @@ -71,6 +72,9 @@ struct vl_dri3_screen
>   xcb_special_event_t *special_event;
>   struct pipe_context *pipe;
> +   struct pipe_resource *output_texture;
> +   uint32_t output_texture_width;
> +   uint32_t output_texture_height;
>   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>   int cur_back;
> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>   xcb_free_pixmap(scrn->conn, buffer->pixmap);
>   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>   xshmfence_unmap_shm(buffer->shm_fence);
> -   pipe_resource_reference(>texture, NULL);
> +   if (!buffer->is_external_texture)
> +  pipe_resource_reference(>texture, NULL);
>   if (buffer->linear_texture)
>   pipe_resource_reference(>linear_texture, NULL);
>   FREE(buffer);
> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
> *scrn)
>   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>   templ.target = PIPE_TEXTURE_2D;
>   templ.last_level = 0;
> -   templ.width0 = scrn->width;
> -   templ.height0 = scrn->height;
> +   if (scrn->output_texture) {
> +  templ.width0 = (scrn->output_texture_width) ?
> + scrn->output_texture_width :
> + scrn->output_texture->width0;
> +  templ.height0 = (scrn->output_texture_height) ?
> +  scrn->output_texture_height :
> +  scrn->output_texture->height0;
> +   } else {
> +   templ.width0 = scrn->width;
> +   templ.height0 = scrn->height;
> +   }
>   templ.depth0 = 1;
>   templ.array_size = 1;
>   if (scrn->is_different_gpu) {
> -  buffer->texture = scrn->base.pscreen->resource_c
> reate(scrn->base.pscreen,
> +  buffer->texture = (scrn->output_texture) ?
> +scrn->output_texture :
> +scrn->base.pscreen->resource_c
> reate(scrn->base.pscreen,
>);
>
 Why not just make it in the same line?

 I was just trying to limit characters to 78 as given in mesa coding
>>> style.
>>>
>>
>> It's really matters if just over a few chars. which way do you think it
>> will look better?
>>
>>
>> I would prefer it in a single line, anyways I just checked that it used
> in single line in entire
> vl code.
>
Damn I miss out some words while I am typing, I meant that this kind of
statements are written in
single line instead of wrapping in the entire vl code, so It makes sense to
have it in that fashion.

>
>
>>
>>>  if (!buffer->texture)
> goto unmap_shm;
> @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> goto no_linear_texture;
>   } else {
>  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> -  buffer->texture = scrn->base.pscreen->resource_c
> 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Thu, Oct 27, 2016 at 10:17 PM, Leo Liu  wrote:

>
>
> On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:
>
>> On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
>>
>>>
>>> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
>>>
 Suggested-by: Leo Liu 
 Signed-off-by: Nayan Deshmukh 
 ---
src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
 +++
2 files changed, 83 insertions(+), 10 deletions(-)

 diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
 b/src/gallium/auxiliary/vl/vl_winsys.h
 index 26db9f2..7c56b48 100644
 --- a/src/gallium/auxiliary/vl/vl_winsys.h
 +++ b/src/gallium/auxiliary/vl/vl_winsys.h
 @@ -59,6 +59,10 @@ struct vl_screen
   void *
   (*get_private)(struct vl_screen *vscreen);
 +   void
 +   (*set_output_texture)(struct vl_screen *vscreen, struct
 pipe_resource *buffer,
 + uint32_t width, uint32_t height);
 +

>>> I think it's more appropriate if it's called
>>> "set_back_texture_from_output"
>>>
>> Yeah that makes more sense.
>>
>>>   struct pipe_screen *pscreen;
   struct pipe_loader_device *dev;
};
 diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 index 2929928..44d6f4c 100644
 --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 @@ -56,6 +56,7 @@ struct vl_dri3_buffer
   struct xshmfence *shm_fence;
   bool busy;
 +   bool is_external_texture;
   uint32_t width, height, pitch;
};
 @@ -71,6 +72,9 @@ struct vl_dri3_screen
   xcb_special_event_t *special_event;
   struct pipe_context *pipe;
 +   struct pipe_resource *output_texture;
 +   uint32_t output_texture_width;
 +   uint32_t output_texture_height;
   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
   int cur_back;
 @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
   xcb_free_pixmap(scrn->conn, buffer->pixmap);
   xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
   xshmfence_unmap_shm(buffer->shm_fence);
 -   pipe_resource_reference(>texture, NULL);
 +   if (!buffer->is_external_texture)
 +  pipe_resource_reference(>texture, NULL);
   if (buffer->linear_texture)
   pipe_resource_reference(>linear_texture, NULL);
   FREE(buffer);
 @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
 *scrn)
   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
   templ.target = PIPE_TEXTURE_2D;
   templ.last_level = 0;
 -   templ.width0 = scrn->width;
 -   templ.height0 = scrn->height;
 +   if (scrn->output_texture) {
 +  templ.width0 = (scrn->output_texture_width) ?
 + scrn->output_texture_width :
 + scrn->output_texture->width0;
 +  templ.height0 = (scrn->output_texture_height) ?
 +  scrn->output_texture_height :
 +  scrn->output_texture->height0;
 +   } else {
 +   templ.width0 = scrn->width;
 +   templ.height0 = scrn->height;
 +   }
   templ.depth0 = 1;
   templ.array_size = 1;
   if (scrn->is_different_gpu) {
 -  buffer->texture = scrn->base.pscreen->resource_c
 reate(scrn->base.pscreen,
 +  buffer->texture = (scrn->output_texture) ?
 +scrn->output_texture :
 +scrn->base.pscreen->resource_c
 reate(scrn->base.pscreen,
);

>>> Why not just make it in the same line?
>>>
>>> I was just trying to limit characters to 78 as given in mesa coding
>> style.
>>
>
> It's really matters if just over a few chars. which way do you think it
> will look better?
>
>
> I would prefer it in a single line, anyways I just checked that it used in
single line in entire
vl code.

>
>>  if (!buffer->texture)
 goto unmap_shm;
 @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 goto no_linear_texture;
   } else {
  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
 -  buffer->texture = scrn->base.pscreen->resource_c
 reate(scrn->base.pscreen,
 +  buffer->texture = (scrn->output_texture) ?
 +scrn->output_texture :
 +scrn->base.pscreen->resource_c
 reate(scrn->base.pscreen,
);

>>> Same as above .
>>>
>>>  if (!buffer->texture)
 goto unmap_shm;
 @@ -271,11 +289,20 @@ 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

On 10/27/2016 12:20 PM, Nayan Deshmukh wrote:

On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:


On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 
---
   src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 
+++
   2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..7c56b48 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
  void *
  (*get_private)(struct vl_screen *vscreen);
+   void
+   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource 
*buffer,
+ uint32_t width, uint32_t height);
+

I think it's more appropriate if it's called "set_back_texture_from_output"

Yeah that makes more sense.

  struct pipe_screen *pscreen;
  struct pipe_loader_device *dev;
   };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..44d6f4c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -56,6 +56,7 @@ struct vl_dri3_buffer
  struct xshmfence *shm_fence;
  bool busy;
+   bool is_external_texture;
  uint32_t width, height, pitch;
   };
@@ -71,6 +72,9 @@ struct vl_dri3_screen
  xcb_special_event_t *special_event;
  struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
  int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
  xcb_free_pixmap(scrn->conn, buffer->pixmap);
  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
  xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
  if (buffer->linear_texture)
  pipe_resource_reference(>linear_texture, NULL);
  FREE(buffer);
@@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
  templ.target = PIPE_TEXTURE_2D;
  templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  templ.width0 = (scrn->output_texture_width) ?
+ scrn->output_texture_width :
+ scrn->output_texture->width0;
+  templ.height0 = (scrn->output_texture_height) ?
+  scrn->output_texture_height :
+  scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   }
  templ.depth0 = 1;
  templ.array_size = 1;
  if (scrn->is_different_gpu) {
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
   );

Why not just make it in the same line?


I was just trying to limit characters to 78 as given in mesa coding style.


It's really matters if just over a few chars. which way do you think it 
will look better?





 if (!buffer->texture)
goto unmap_shm;
@@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
goto no_linear_texture;
  } else {
 templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
   );

Same as above .


 if (!buffer->texture)
goto unmap_shm;
@@ -271,11 +289,20 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
  usage);
  buffer_fd = whandle.handle;
  buffer->pitch = whandle.stride;
+   buffer->width = templ.width0;
+   buffer->height = templ.height0;
+   buffer->is_external_texture = (scrn->output_texture) ?
+ true :
+ false;

Same as above.


+   scrn->output_texture = NULL;
+   scrn->output_texture_width = 0;
+   scrn->output_texture_height = 0;
+
  xcb_dri3_pixmap_from_buffer(scrn->conn,
  (pixmap = xcb_generate_id(scrn->conn)),
  scrn->drawable,
  0,
-  

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Thu, Oct 27, 2016 at 10:38:30AM -0400, Leo Liu wrote:
> 
> 
> On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:
> > Suggested-by: Leo Liu 
> > Signed-off-by: Nayan Deshmukh 
> > ---
> >   src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
> >   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 
> > +++
> >   2 files changed, 83 insertions(+), 10 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> > b/src/gallium/auxiliary/vl/vl_winsys.h
> > index 26db9f2..7c56b48 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > @@ -59,6 +59,10 @@ struct vl_screen
> >  void *
> >  (*get_private)(struct vl_screen *vscreen);
> > +   void
> > +   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource 
> > *buffer,
> > + uint32_t width, uint32_t height);
> > +
> 
> I think it's more appropriate if it's called "set_back_texture_from_output"
Yeah that makes more sense.
> 
> >  struct pipe_screen *pscreen;
> >  struct pipe_loader_device *dev;
> >   };
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> > b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > index 2929928..44d6f4c 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > @@ -56,6 +56,7 @@ struct vl_dri3_buffer
> >  struct xshmfence *shm_fence;
> >  bool busy;
> > +   bool is_external_texture;
> >  uint32_t width, height, pitch;
> >   };
> > @@ -71,6 +72,9 @@ struct vl_dri3_screen
> >  xcb_special_event_t *special_event;
> >  struct pipe_context *pipe;
> > +   struct pipe_resource *output_texture;
> > +   uint32_t output_texture_width;
> > +   uint32_t output_texture_height;
> >  struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> >  int cur_back;
> > @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> >  xcb_free_pixmap(scrn->conn, buffer->pixmap);
> >  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> >  xshmfence_unmap_shm(buffer->shm_fence);
> > -   pipe_resource_reference(>texture, NULL);
> > +   if (!buffer->is_external_texture)
> > +  pipe_resource_reference(>texture, NULL);
> >  if (buffer->linear_texture)
> >  pipe_resource_reference(>linear_texture, NULL);
> >  FREE(buffer);
> > @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> >  templ.target = PIPE_TEXTURE_2D;
> >  templ.last_level = 0;
> > -   templ.width0 = scrn->width;
> > -   templ.height0 = scrn->height;
> > +   if (scrn->output_texture) {
> > +  templ.width0 = (scrn->output_texture_width) ?
> > + scrn->output_texture_width :
> > + scrn->output_texture->width0;
> > +  templ.height0 = (scrn->output_texture_height) ?
> > +  scrn->output_texture_height :
> > +  scrn->output_texture->height0;
> > +   } else {
> > +   templ.width0 = scrn->width;
> > +   templ.height0 = scrn->height;
> > +   }
> >  templ.depth0 = 1;
> >  templ.array_size = 1;
> >  if (scrn->is_different_gpu) {
> > -  buffer->texture = 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > +  buffer->texture = (scrn->output_texture) ?
> > +scrn->output_texture :
> > +
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> >   );
> 
> Why not just make it in the same line?
> 
I was just trying to limit characters to 78 as given in mesa coding style.

> > if (!buffer->texture)
> >goto unmap_shm;
> > @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >goto no_linear_texture;
> >  } else {
> > templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> > -  buffer->texture = 
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> > +  buffer->texture = (scrn->output_texture) ?
> > +scrn->output_texture :
> > +
> > scrn->base.pscreen->resource_create(scrn->base.pscreen,
> >   );
> 
> Same as above .
> 
> > if (!buffer->texture)
> >goto unmap_shm;
> > @@ -271,11 +289,20 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> >  usage);
> >  buffer_fd = whandle.handle;
> >  buffer->pitch = whandle.stride;
> > +   buffer->width = templ.width0;
> > +   buffer->height = templ.height0;
> > +   buffer->is_external_texture = (scrn->output_texture) ?
> > + true :
> > + false;
> 
> Same as above.
> 
> > +   scrn->output_texture = NULL;
> > +   scrn->output_texture_width 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

On 10/24/2016 09:55 AM, Nayan Deshmukh wrote:

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 +++
  2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..7c56b48 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  
+   void

+   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource 
*buffer,
+ uint32_t width, uint32_t height);
+


I think it's more appropriate if it's called "set_back_texture_from_output"


 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..44d6f4c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -56,6 +56,7 @@ struct vl_dri3_buffer
 struct xshmfence *shm_fence;
  
 bool busy;

+   bool is_external_texture;
 uint32_t width, height, pitch;
  };
  
@@ -71,6 +72,9 @@ struct vl_dri3_screen

 xcb_special_event_t *special_event;
  
 struct pipe_context *pipe;

+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
  
 struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];

 int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  templ.width0 = (scrn->output_texture_width) ?
+ scrn->output_texture_width :
+ scrn->output_texture->width0;
+  templ.height0 = (scrn->output_texture_height) ?
+  scrn->output_texture_height :
+  scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   }
 templ.depth0 = 1;
 templ.array_size = 1;
  
 if (scrn->is_different_gpu) {

-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
  );


Why not just make it in the same line?


if (!buffer->texture)
   goto unmap_shm;
@@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
   goto no_linear_texture;
 } else {
templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
  );


Same as above .


if (!buffer->texture)
   goto unmap_shm;
@@ -271,11 +289,20 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 usage);
 buffer_fd = whandle.handle;
 buffer->pitch = whandle.stride;
+   buffer->width = templ.width0;
+   buffer->height = templ.height0;
+   buffer->is_external_texture = (scrn->output_texture) ?
+ true :
+ false;


Same as above.


+   scrn->output_texture = NULL;
+   scrn->output_texture_width = 0;
+   scrn->output_texture_height = 0;
+
 xcb_dri3_pixmap_from_buffer(scrn->conn,
 (pixmap = xcb_generate_id(scrn->conn)),
 scrn->drawable,
 0,
-   scrn->width, scrn->height, buffer->pitch,
+   buffer->width, buffer->height, buffer->pitch,


The width/height here should be same as buffer texture width/height.
That's case before, now that is changed to

  templ.width0 = (scrn->output_texture_width) ?

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Nayan Deshmukh wrote:

On Thu, Oct 27, 2016 at 11:52:13AM +0100, Andy Furniss wrote:

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.


This reason for this is that in case of single gpu, I have to recalculate
its handle and get a pixmap from that buffer for each frame. This calulation
is avoided due to the presence of a linear buffer in case of different gpu.


OK, possibly I misunderstand your answer, but I don't think any extra
calculation is the issue, it's purely that I loose pageflip. By which
I mean without your patches I can reproduce with R600_DEBUG=notiling.
Powerplay is not giving me enough on auto, but TBH I may not like it
if I had to be permanently higher/hotter to handle just one case.
Maybe the timing/efficiency of display copies is an issue - I don't know.



Regards,
Nayan


Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.

Tested with CPU forced high, so it's not CPU freq.






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Thu, Oct 27, 2016 at 11:52:13AM +0100, Andy Furniss wrote:
> Andy Furniss wrote:
> > Michel Dänzer wrote:
> > > On 26/10/16 08:07 PM, Andy Furniss wrote:
> > > > 
> > > > The bad = Starting with DRI3 (which is default) I still get trashed
> > > > rendering full screen. Windowed including re-sizing seems OK.
> > > > 
> > > > I use Fluxbox window manager, which does not use compositing -
> > > > IIRC this has historically shown some ddx DRI2/3 issue that wasn't
> > > > visible to those testing with compositing (but then the full screen
> > > > case may avoid compositing anyway depending on settings).
> > > 
> > > You may be running into a DDX driver issue fixed by
> > > https://patchwork.freedesktop.org/patch/118514/ .
> > 
> > Yes, that was it, OK with that patch.
> 
> Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
> fails top 5% of screen unless I force GPU perf high.

This reason for this is that in case of single gpu, I have to recalculate 
its handle and get a pixmap from that buffer for each frame. This calulation 
is avoided due to the presence of a linear buffer in case of different gpu.

Regards,
Nayan
> 
> Not related to this patch directly of course, but I am a bit surprised
> that on auto powerplay the tonga is too slow to make 60Hz.
> 
> Tested with CPU forced high, so it's not CPU freq.
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Andy Furniss wrote:

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
fails top 5% of screen unless I force GPU perf high.

Not related to this patch directly of course, but I am a bit surprised
that on auto powerplay the tonga is too slow to make 60Hz.

Tested with CPU forced high, so it's not CPU freq.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:

On 26/10/16 08:07 PM, Andy Furniss wrote:


The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


Yes, that was it, OK with that patch.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

s/runs/null/ 
On Wed, Oct 26, 2016 at 01:57:12AM +0530, Nayan Deshmukh wrote:
> Hi Andy,
> 
> It seems that you have compiled mesa with DRI3 enabled but 
> vl_dri3_screen_create returns 
> runs when called in device.c and hence VDPAU fallbacks to using DRI2.
> 
> BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in 
> case of a 
> fallback.
> 
> Regards,
> Nayan.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Tue, Oct 25, 2016 at 11:11:13PM +0100, Andy Furniss wrote:
> Nayan Deshmukh wrote:
> > Hi Andy,
> > 
> > It seems that you have compiled mesa with DRI3 enabled but 
> > vl_dri3_screen_create returns
> > runs when called in device.c and hence VDPAU fallbacks to using DRI2.
> > 
> > BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in 
> > case of a
> > fallback.
> 
> Patch 3 won't apply with new patch 2
Sorry about that. I forgot to send the patch 3 which had to 
rebased upon updated patch 2 so that it can be appplied. I 
have sent the updated patch.

Regards,
Nayan. 
> 
> error: patch failed: src/gallium/state_trackers/vdpau/presentation.c:252
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Michel Dänzer]

On 26/10/16 08:07 PM, Andy Furniss wrote:
>
> The bad = Starting with DRI3 (which is default) I still get trashed
> rendering full screen. Windowed including re-sizing seems OK.
> 
> I use Fluxbox window manager, which does not use compositing -
> IIRC this has historically shown some ddx DRI2/3 issue that wasn't
> visible to those testing with compositing (but then the full screen
> case may avoid compositing anyway depending on settings).

You may be running into a DDX driver issue fixed by
https://patchwork.freedesktop.org/patch/118514/ .


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Nayan Deshmukh wrote:

On Tue, Oct 25, 2016 at 11:11:13PM +0100, Andy Furniss wrote:

Nayan Deshmukh wrote:

Hi Andy,

It seems that you have compiled mesa with DRI3 enabled but 
vl_dri3_screen_create returns
runs when called in device.c and hence VDPAU fallbacks to using DRI2.

BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in case 
of a
fallback.


Patch 3 won't apply with new patch 2

Sorry about that. I forgot to send the patch 3 which had to
rebased upon updated patch 2 so that it can be appplied. I
have sent the updated patch.


Ok, thanks.

The good = If I startx with DRI3 disabled (in ddx) then it works.
Previously I would segfault with mpv vdpau vo.

The bad = Starting with DRI3 (which is default) I still get trashed
rendering full screen. Windowed including re-sizing seems OK.

I use Fluxbox window manager, which does not use compositing -
IIRC this has historically shown some ddx DRI2/3 issue that wasn't
visible to those testing with compositing (but then the full screen
case may avoid compositing anyway depending on settings).


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Nayan Deshmukh wrote:

Hi Andy,

It seems that you have compiled mesa with DRI3 enabled but 
vl_dri3_screen_create returns
runs when called in device.c and hence VDPAU fallbacks to using DRI2.

BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in case 
of a
fallback.


Patch 3 won't apply with new patch 2

error: patch failed: src/gallium/state_trackers/vdpau/presentation.c:252

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

Hi Andy,

It seems that you have compiled mesa with DRI3 enabled but 
vl_dri3_screen_create returns 
runs when called in device.c and hence VDPAU fallbacks to using DRI2.

BTW I have sent in the v1.1 for patch 2 which play the video using dri2 in case 
of a 
fallback.

Regards,
Nayan.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Leo Liu wrote:



On 10/25/2016 02:42 PM, Andy Furniss wrote:

Christian König wrote:

Nice work, have you been able to fix all the issues you mentioned on
your last mail?

Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
it's available or not.

Keep in mind that we possible compile both DRI2 and DRI3 into the
driver, but it can happen that we fallback to DRI2 on runtime.


Patch 2 for me is corrupted fullscreen.

Seems I have a mix of DRI2 and 3 according to below anyway.

Am I supposed to be compiling xserver, amdgpu (ddx) or mesa in some
way that avoids this?

grep DRI /var/log/Xorg.0.log
[ 35587.890] (II) glamor: EGL version 1.4 (DRI2):
[ 35588.093] (II) AMDGPU(0): [DRI2] Setup complete
[ 35588.093] (II) AMDGPU(0): [DRI2]   DRI driver: radeonsi
[ 35588.093] (II) AMDGPU(0): [DRI2]   VDPAU driver: radeonsi
[ 35588.093] (==) AMDGPU(0): DRI3 enabled
[ 35588.246] (II) GLX: Initialized DRI2 GL provider for screen 0


That's nothing wrong. X set up services for both DRI2 and DRI3, so you
have seen messages for both.


Thanks, I thought I'd better ask, just in case I was doing something 
stupid somewhere.



You need check your client side if DRI3 is enabled.
For mesa, run `LIBGL_DEBUG=verbose glxinfo > /dev/null', then should see
something like "using DRI3 for screen..."
If no, then rebuild mesa


libGL: Using DRI3 for screen 0


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

On 10/25/2016 02:42 PM, Andy Furniss wrote:

Christian König wrote:

Nice work, have you been able to fix all the issues you mentioned on
your last mail?

Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
it's available or not.

Keep in mind that we possible compile both DRI2 and DRI3 into the
driver, but it can happen that we fallback to DRI2 on runtime.


Patch 2 for me is corrupted fullscreen.

Seems I have a mix of DRI2 and 3 according to below anyway.

Am I supposed to be compiling xserver, amdgpu (ddx) or mesa in some
way that avoids this?

grep DRI /var/log/Xorg.0.log
[ 35587.890] (II) glamor: EGL version 1.4 (DRI2):
[ 35588.093] (II) AMDGPU(0): [DRI2] Setup complete
[ 35588.093] (II) AMDGPU(0): [DRI2]   DRI driver: radeonsi
[ 35588.093] (II) AMDGPU(0): [DRI2]   VDPAU driver: radeonsi
[ 35588.093] (==) AMDGPU(0): DRI3 enabled
[ 35588.246] (II) GLX: Initialized DRI2 GL provider for screen 0


That's nothing wrong. X set up services for both DRI2 and DRI3, so you 
have seen messages for both.


You need check your client side if DRI3 is enabled.
For mesa, run `LIBGL_DEBUG=verbose glxinfo > /dev/null', then should see 
something like "using DRI3 for screen..."

If no, then rebuild mesa

Regards,
Leo





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Christian König wrote:

Nice work, have you been able to fix all the issues you mentioned on
your last mail?

Additional to that make sure that this set also keeps DRI2 working, in
patch #2 it looks like you call the new function without checking if
it's available or not.

Keep in mind that we possible compile both DRI2 and DRI3 into the
driver, but it can happen that we fallback to DRI2 on runtime.


Patch 2 for me is corrupted fullscreen.

Seems I have a mix of DRI2 and 3 according to below anyway.

Am I supposed to be compiling xserver, amdgpu (ddx) or mesa in some
way that avoids this?

grep DRI /var/log/Xorg.0.log
[ 35587.890] (II) glamor: EGL version 1.4 (DRI2):
[ 35588.093] (II) AMDGPU(0): [DRI2] Setup complete
[ 35588.093] (II) AMDGPU(0): [DRI2]   DRI driver: radeonsi
[ 35588.093] (II) AMDGPU(0): [DRI2]   VDPAU driver: radeonsi
[ 35588.093] (==) AMDGPU(0): DRI3 enabled
[ 35588.246] (II) GLX: Initialized DRI2 GL provider for screen 0


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Tue, Oct 25, 2016 at 11:08:12AM -0400, Leo Liu wrote:
> 
> 
> On 10/25/2016 02:01 AM, Nayan Deshmukh wrote:
> > Hi Leo,
> > 
> > On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:
> > > There are a couple of other issues from a brief test:
> > > 
> > > 1. Compile warnings for presentation.c.
> > I will fix this in v2 with the changes that christian suggested, it might be
> > because of the use of #if which would anyway be removed with the change 
> > christian
> > suggested.
> > > 2. When window resized, it's showing corruption, and sometimes corruption
> > > will stay.
> > > 
> > It works fine on my system, I get a brief corruption while resizing but it
> > never stays.
> > 
> > Can you look into and see what is causing it as I am not able to reproduce
> > it on my system. It may be the case of a single GPU which is causing the 
> > problem.
> 
> I am busy with other things this week, and get better later or next week.
That works for me, you can have a look at it whenever you are free.
> 
> I haven't looked your patch in detail, but notice many of new structure
> member added
> for scrn and buffer, so please make sure to be concise and no redundant.
>
I have tried my best to avoid redundancy, still I will check if the patch can 
be improved further and post updates.

Regards,
Nayan. 
> Regards,
> Leo
> 
> 
> > 
> > Regards,
> > Nayan.
> > > Regards,
> > > Leo
> > > 
> > > 
> > > On 10/24/2016 11:27 AM, Nayan Deshmukh wrote:
> > > > 
> > > > On Mon, Oct 24, 2016 at 8:48 PM, Christian König
> > > > > wrote:
> > > > 
> > > >  Nice work, have you been able to fix all the issues you mentioned
> > > >  on your last mail?
> > > > 
> > > > Yes, it fixes all the known issues. But I have only tested it on my
> > > > system.
> > > > 
> > > >  Additional to that make sure that this set also keeps DRI2
> > > >  working, in patch #2 it looks like you call the new function
> > > >  without checking if it's available or not.
> > > > 
> > > > 
> > > >  Keep in mind that we possible compile both DRI2 and DRI3 into the
> > > >  driver, but it can happen that we fallback to DRI2 on runtime.
> > > > 
> > > > I missed this case, it will won't work if we fallback to DRI2 on runtime
> > > > I will send a v2 to take care of this.
> > > > 
> > > > Regards,
> > > > Nayan.
> > > > 
> > > >  Regards,
> > > >  Christian.
> > > > 
> > > > 
> > > >  Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:
> > > > 
> > > >  Suggested-by: Leo Liu  > > > >
> > > >  Signed-off-by: Nayan Deshmukh  > > >  >
> > > >  ---
> > > >src/gallium/auxiliary/vl/vl_winsys.h  | 4 ++
> > > >src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
> > > >  +++
> > > >2 files changed, 83 insertions(+), 10 deletions(-)
> > > > 
> > > >  diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> > > >  b/src/gallium/auxiliary/vl/vl_winsys.h
> > > >  index 26db9f2..7c56b48 100644
> > > >  --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > > >  +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > > >  @@ -59,6 +59,10 @@ struct vl_screen
> > > >   void *
> > > >   (*get_private)(struct vl_screen *vscreen);
> > > >+   void
> > > >  +   (*set_output_texture)(struct vl_screen *vscreen, struct
> > > >  pipe_resource *buffer,
> > > >  + uint32_t width, uint32_t height);
> > > >  +
> > > >   struct pipe_screen *pscreen;
> > > >   struct pipe_loader_device *dev;
> > > >};
> > > >  diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > > >  b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > > >  index 2929928..44d6f4c 100644
> > > >  --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > > >  +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > > >  @@ -56,6 +56,7 @@ struct vl_dri3_buffer
> > > >   struct xshmfence *shm_fence;
> > > > bool busy;
> > > >  +   bool is_external_texture;
> > > >   uint32_t width, height, pitch;
> > > >};
> > > >@@ -71,6 +72,9 @@ struct vl_dri3_screen
> > > >   xcb_special_event_t *special_event;
> > > > struct pipe_context *pipe;
> > > >  +   struct pipe_resource *output_texture;
> > > >  +   uint32_t output_texture_width;
> > > >  +   uint32_t output_texture_height;
> > > > struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> > > >   int cur_back;
> > > >  @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct
> > > >  vl_dri3_screen *scrn,
> > > >   

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

On 10/25/2016 02:01 AM, Nayan Deshmukh wrote:

Hi Leo,

On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:

There are a couple of other issues from a brief test:

1. Compile warnings for presentation.c.

I will fix this in v2 with the changes that christian suggested, it might be
because of the use of #if which would anyway be removed with the change 
christian
suggested.

2. When window resized, it's showing corruption, and sometimes corruption
will stay.


It works fine on my system, I get a brief corruption while resizing but it
never stays.

Can you look into and see what is causing it as I am not able to reproduce
it on my system. It may be the case of a single GPU which is causing the 
problem.


I am busy with other things this week, and get better later or next week.

I haven't looked your patch in detail, but notice many of new structure 
member added

for scrn and buffer, so please make sure to be concise and no redundant.

Regards,
Leo




Regards,
Nayan.

Regards,
Leo


On 10/24/2016 11:27 AM, Nayan Deshmukh wrote:


On Mon, Oct 24, 2016 at 8:48 PM, Christian König
> wrote:

 Nice work, have you been able to fix all the issues you mentioned
 on your last mail?

Yes, it fixes all the known issues. But I have only tested it on my
system.

 Additional to that make sure that this set also keeps DRI2
 working, in patch #2 it looks like you call the new function
 without checking if it's available or not.


 Keep in mind that we possible compile both DRI2 and DRI3 into the
 driver, but it can happen that we fallback to DRI2 on runtime.

I missed this case, it will won't work if we fallback to DRI2 on runtime
I will send a v2 to take care of this.

Regards,
Nayan.

 Regards,
 Christian.


 Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:

 Suggested-by: Leo Liu >
 Signed-off-by: Nayan Deshmukh >
 ---
   src/gallium/auxiliary/vl/vl_winsys.h  | 4 ++
   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
 +++
   2 files changed, 83 insertions(+), 10 deletions(-)

 diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
 b/src/gallium/auxiliary/vl/vl_winsys.h
 index 26db9f2..7c56b48 100644
 --- a/src/gallium/auxiliary/vl/vl_winsys.h
 +++ b/src/gallium/auxiliary/vl/vl_winsys.h
 @@ -59,6 +59,10 @@ struct vl_screen
  void *
  (*get_private)(struct vl_screen *vscreen);
   +   void
 +   (*set_output_texture)(struct vl_screen *vscreen, struct
 pipe_resource *buffer,
 + uint32_t width, uint32_t height);
 +
  struct pipe_screen *pscreen;
  struct pipe_loader_device *dev;
   };
 diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 index 2929928..44d6f4c 100644
 --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
 @@ -56,6 +56,7 @@ struct vl_dri3_buffer
  struct xshmfence *shm_fence;
bool busy;
 +   bool is_external_texture;
  uint32_t width, height, pitch;
   };
   @@ -71,6 +72,9 @@ struct vl_dri3_screen
  xcb_special_event_t *special_event;
struct pipe_context *pipe;
 +   struct pipe_resource *output_texture;
 +   uint32_t output_texture_width;
 +   uint32_t output_texture_height;
struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
  int cur_back;
 @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct
 vl_dri3_screen *scrn,
  xcb_free_pixmap(scrn->conn, buffer->pixmap);
  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
  xshmfence_unmap_shm(buffer->shm_fence);
 -   pipe_resource_reference(>texture, NULL);
 +   if (!buffer->is_external_texture)
 +  pipe_resource_reference(>texture, NULL);
  if (buffer->linear_texture)
  pipe_resource_reference(>linear_texture, NULL);
  FREE(buffer);
 @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct
 vl_dri3_screen *scrn)
  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
  templ.target = PIPE_TEXTURE_2D;
  templ.last_level = 0;
 -   templ.width0 = scrn->width;
 -   templ.height0 = scrn->height;
 +   if (scrn->output_texture) {
 +  templ.width0 = (scrn->output_texture_width) ?
 + scrn->output_texture_width :
 +  scrn->output_texture->width0;
 +  templ.height0 = (scrn->output_texture_height) ?
 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

Hi Leo,

On Mon, Oct 24, 2016 at 03:18:19PM -0400, Leo Liu wrote:
> There are a couple of other issues from a brief test:
> 
> 1. Compile warnings for presentation.c.
I will fix this in v2 with the changes that christian suggested, it might be 
because of the use of #if which would anyway be removed with the change 
christian
suggested.  
> 
> 2. When window resized, it's showing corruption, and sometimes corruption
> will stay.
> 
It works fine on my system, I get a brief corruption while resizing but it 
never stays. 

Can you look into and see what is causing it as I am not able to reproduce
it on my system. It may be the case of a single GPU which is causing the 
problem.

Regards,
Nayan.
> Regards,
> Leo
> 
> 
> On 10/24/2016 11:27 AM, Nayan Deshmukh wrote:
> > 
> > 
> > On Mon, Oct 24, 2016 at 8:48 PM, Christian König
> > > wrote:
> > 
> > Nice work, have you been able to fix all the issues you mentioned
> > on your last mail?
> > 
> > Yes, it fixes all the known issues. But I have only tested it on my
> > system.
> > 
> > Additional to that make sure that this set also keeps DRI2
> > working, in patch #2 it looks like you call the new function
> > without checking if it's available or not.
> > 
> > 
> > Keep in mind that we possible compile both DRI2 and DRI3 into the
> > driver, but it can happen that we fallback to DRI2 on runtime.
> > 
> > I missed this case, it will won't work if we fallback to DRI2 on runtime
> > I will send a v2 to take care of this.
> > 
> > Regards,
> > Nayan.
> > 
> > Regards,
> > Christian.
> > 
> > 
> > Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:
> > 
> > Suggested-by: Leo Liu >
> > Signed-off-by: Nayan Deshmukh  > >
> > ---
> >   src/gallium/auxiliary/vl/vl_winsys.h  | 4 ++
> >   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
> > +++
> >   2 files changed, 83 insertions(+), 10 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
> > b/src/gallium/auxiliary/vl/vl_winsys.h
> > index 26db9f2..7c56b48 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys.h
> > +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> > @@ -59,6 +59,10 @@ struct vl_screen
> >  void *
> >  (*get_private)(struct vl_screen *vscreen);
> >   +   void
> > +   (*set_output_texture)(struct vl_screen *vscreen, struct
> > pipe_resource *buffer,
> > + uint32_t width, uint32_t height);
> > +
> >  struct pipe_screen *pscreen;
> >  struct pipe_loader_device *dev;
> >   };
> > diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > index 2929928..44d6f4c 100644
> > --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> > @@ -56,6 +56,7 @@ struct vl_dri3_buffer
> >  struct xshmfence *shm_fence;
> >bool busy;
> > +   bool is_external_texture;
> >  uint32_t width, height, pitch;
> >   };
> >   @@ -71,6 +72,9 @@ struct vl_dri3_screen
> >  xcb_special_event_t *special_event;
> >struct pipe_context *pipe;
> > +   struct pipe_resource *output_texture;
> > +   uint32_t output_texture_width;
> > +   uint32_t output_texture_height;
> >struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> >  int cur_back;
> > @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct
> > vl_dri3_screen *scrn,
> >  xcb_free_pixmap(scrn->conn, buffer->pixmap);
> >  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> >  xshmfence_unmap_shm(buffer->shm_fence);
> > -   pipe_resource_reference(>texture, NULL);
> > +   if (!buffer->is_external_texture)
> > +  pipe_resource_reference(>texture, NULL);
> >  if (buffer->linear_texture)
> >  pipe_resource_reference(>linear_texture, NULL);
> >  FREE(buffer);
> > @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct
> > vl_dri3_screen *scrn)
> >  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> >  templ.target = PIPE_TEXTURE_2D;
> >  templ.last_level = 0;
> > -   templ.width0 = scrn->width;
> > -   templ.height0 = scrn->height;
> > +   if (scrn->output_texture) {
> > +  templ.width0 = (scrn->output_texture_width) ?
> > + scrn->output_texture_width :
> > +  scrn->output_texture->width0;
> > +  templ.height0 = 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Leo Liu]

There are a couple of other issues from a brief test:

1. Compile warnings for presentation.c.

2. When window resized, it's showing corruption, and sometimes 
corruption will stay.


Regards,
Leo


On 10/24/2016 11:27 AM, Nayan Deshmukh wrote:



On Mon, Oct 24, 2016 at 8:48 PM, Christian König 
> wrote:


Nice work, have you been able to fix all the issues you mentioned
on your last mail?

Yes, it fixes all the known issues. But I have only tested it on my 
system.


Additional to that make sure that this set also keeps DRI2
working, in patch #2 it looks like you call the new function
without checking if it's available or not. 



Keep in mind that we possible compile both DRI2 and DRI3 into the
driver, but it can happen that we fallback to DRI2 on runtime.

I missed this case, it will won't work if we fallback to DRI2 on 
runtime I will send a v2 to take care of this.


Regards,
Nayan.

Regards,
Christian.


Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:

Suggested-by: Leo Liu >
Signed-off-by: Nayan Deshmukh >
---
  src/gallium/auxiliary/vl/vl_winsys.h  | 4 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
+++
  2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..7c56b48 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  +   void
+   (*set_output_texture)(struct vl_screen *vscreen, struct
pipe_resource *buffer,
+ uint32_t width, uint32_t height);
+
 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..44d6f4c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -56,6 +56,7 @@ struct vl_dri3_buffer
 struct xshmfence *shm_fence;
   bool busy;
+   bool is_external_texture;
 uint32_t width, height, pitch;
  };
  @@ -71,6 +72,9 @@ struct vl_dri3_screen
 xcb_special_event_t *special_event;
   struct pipe_context *pipe;
+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
   struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
 int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct
vl_dri3_screen *scrn,
 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct
vl_dri3_screen *scrn)
 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  templ.width0 = (scrn->output_texture_width) ?
+ scrn->output_texture_width :
+  scrn->output_texture->width0;
+  templ.height0 = (scrn->output_texture_height) ?
+ scrn->output_texture_height :
+ scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   }
 templ.depth0 = 1;
 templ.array_size = 1;
   if (scrn->is_different_gpu) {
-  buffer->texture =
scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+ scrn->base.pscreen->resource_create(scrn->base.pscreen,
  );
if (!buffer->texture)
   goto unmap_shm;
@@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct
vl_dri3_screen *scrn)
   goto no_linear_texture;
 } else {
templ.bind |= 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Nayan Deshmukh]

On Mon, Oct 24, 2016 at 8:48 PM, Christian König 
wrote:

> Nice work, have you been able to fix all the issues you mentioned on your
> last mail?
>
> Yes, it fixes all the known issues. But I have only tested it on my
system.

> Additional to that make sure that this set also keeps DRI2 working, in
> patch #2 it looks like you call the new function without checking if it's
> available or not.


>
Keep in mind that we possible compile both DRI2 and DRI3 into the driver,
> but it can happen that we fallback to DRI2 on runtime.
>
> I missed this case, it will won't work if we fallback to DRI2 on runtime I
will send a v2 to take care of this.

Regards,
Nayan.

> Regards,
> Christian.
>
>
> Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:
>
>> Suggested-by: Leo Liu 
>> Signed-off-by: Nayan Deshmukh 
>> ---
>>   src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
>>   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89
>> +++
>>   2 files changed, 83 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
>> b/src/gallium/auxiliary/vl/vl_winsys.h
>> index 26db9f2..7c56b48 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys.h
>> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
>> @@ -59,6 +59,10 @@ struct vl_screen
>>  void *
>>  (*get_private)(struct vl_screen *vscreen);
>>   +   void
>> +   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource
>> *buffer,
>> + uint32_t width, uint32_t height);
>> +
>>  struct pipe_screen *pscreen;
>>  struct pipe_loader_device *dev;
>>   };
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 2929928..44d6f4c 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -56,6 +56,7 @@ struct vl_dri3_buffer
>>  struct xshmfence *shm_fence;
>>bool busy;
>> +   bool is_external_texture;
>>  uint32_t width, height, pitch;
>>   };
>>   @@ -71,6 +72,9 @@ struct vl_dri3_screen
>>  xcb_special_event_t *special_event;
>>struct pipe_context *pipe;
>> +   struct pipe_resource *output_texture;
>> +   uint32_t output_texture_width;
>> +   uint32_t output_texture_height;
>>struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>>  int cur_back;
>> @@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>>  xcb_free_pixmap(scrn->conn, buffer->pixmap);
>>  xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>>  xshmfence_unmap_shm(buffer->shm_fence);
>> -   pipe_resource_reference(>texture, NULL);
>> +   if (!buffer->is_external_texture)
>> +  pipe_resource_reference(>texture, NULL);
>>  if (buffer->linear_texture)
>>  pipe_resource_reference(>linear_texture, NULL);
>>  FREE(buffer);
>> @@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>>  templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>>  templ.target = PIPE_TEXTURE_2D;
>>  templ.last_level = 0;
>> -   templ.width0 = scrn->width;
>> -   templ.height0 = scrn->height;
>> +   if (scrn->output_texture) {
>> +  templ.width0 = (scrn->output_texture_width) ?
>> + scrn->output_texture_width :
>> + scrn->output_texture->width0;
>> +  templ.height0 = (scrn->output_texture_height) ?
>> +  scrn->output_texture_height :
>> +  scrn->output_texture->height0;
>> +   } else {
>> +   templ.width0 = scrn->width;
>> +   templ.height0 = scrn->height;
>> +   }
>>  templ.depth0 = 1;
>>  templ.array_size = 1;
>>if (scrn->is_different_gpu) {
>> -  buffer->texture = scrn->base.pscreen->resource_c
>> reate(scrn->base.pscreen,
>> +  buffer->texture = (scrn->output_texture) ?
>> +scrn->output_texture :
>> +scrn->base.pscreen->resource_c
>> reate(scrn->base.pscreen,
>>   );
>> if (!buffer->texture)
>>goto unmap_shm;
>> @@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>>goto no_linear_texture;
>>  } else {
>> templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
>> -  buffer->texture = scrn->base.pscreen->resource_c
>> reate(scrn->base.pscreen,
>> +  buffer->texture = (scrn->output_texture) ?
>> +scrn->output_texture :
>> +scrn->base.pscreen->resource_c
>> reate(scrn->base.pscreen,
>>   );
>> if (!buffer->texture)
>>goto unmap_shm;
>> @@ -271,11 +289,20 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>>  usage);
>>  buffer_fd = whandle.handle;
>>  buffer->pitch = whandle.stride;
>> +   

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Christian König]

Nice work, have you been able to fix all the issues you mentioned on 
your last mail?


Additional to that make sure that this set also keeps DRI2 working, in 
patch #2 it looks like you call the new function without checking if 
it's available or not.


Keep in mind that we possible compile both DRI2 and DRI3 into the 
driver, but it can happen that we fallback to DRI2 on runtime.


Regards,
Christian.

Am 24.10.2016 um 15:55 schrieb Nayan Deshmukh:

Suggested-by: Leo Liu 
Signed-off-by: Nayan Deshmukh 
---
  src/gallium/auxiliary/vl/vl_winsys.h  |  4 ++
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 89 +++
  2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..7c56b48 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,10 @@ struct vl_screen
 void *
 (*get_private)(struct vl_screen *vscreen);
  
+   void

+   (*set_output_texture)(struct vl_screen *vscreen, struct pipe_resource 
*buffer,
+ uint32_t width, uint32_t height);
+
 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
  };
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 2929928..44d6f4c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -56,6 +56,7 @@ struct vl_dri3_buffer
 struct xshmfence *shm_fence;
  
 bool busy;

+   bool is_external_texture;
 uint32_t width, height, pitch;
  };
  
@@ -71,6 +72,9 @@ struct vl_dri3_screen

 xcb_special_event_t *special_event;
  
 struct pipe_context *pipe;

+   struct pipe_resource *output_texture;
+   uint32_t output_texture_width;
+   uint32_t output_texture_height;
  
 struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];

 int cur_back;
@@ -105,7 +109,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
 xcb_free_pixmap(scrn->conn, buffer->pixmap);
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
-   pipe_resource_reference(>texture, NULL);
+   if (!buffer->is_external_texture)
+  pipe_resource_reference(>texture, NULL);
 if (buffer->linear_texture)
 pipe_resource_reference(>linear_texture, NULL);
 FREE(buffer);
@@ -236,13 +241,24 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
 templ.target = PIPE_TEXTURE_2D;
 templ.last_level = 0;
-   templ.width0 = scrn->width;
-   templ.height0 = scrn->height;
+   if (scrn->output_texture) {
+  templ.width0 = (scrn->output_texture_width) ?
+ scrn->output_texture_width :
+ scrn->output_texture->width0;
+  templ.height0 = (scrn->output_texture_height) ?
+  scrn->output_texture_height :
+  scrn->output_texture->height0;
+   } else {
+   templ.width0 = scrn->width;
+   templ.height0 = scrn->height;
+   }
 templ.depth0 = 1;
 templ.array_size = 1;
  
 if (scrn->is_different_gpu) {

-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
  );
if (!buffer->texture)
   goto unmap_shm;
@@ -257,7 +273,9 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
   goto no_linear_texture;
 } else {
templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
-  buffer->texture = scrn->base.pscreen->resource_create(scrn->base.pscreen,
+  buffer->texture = (scrn->output_texture) ?
+scrn->output_texture :
+scrn->base.pscreen->resource_create(scrn->base.pscreen,
  );
if (!buffer->texture)
   goto unmap_shm;
@@ -271,11 +289,20 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 usage);
 buffer_fd = whandle.handle;
 buffer->pitch = whandle.stride;
+   buffer->width = templ.width0;
+   buffer->height = templ.height0;
+   buffer->is_external_texture = (scrn->output_texture) ?
+ true :
+ false;
+   scrn->output_texture = NULL;
+   scrn->output_texture_width = 0;
+   scrn->output_texture_height = 0;
+
 xcb_dri3_pixmap_from_buffer(scrn->conn,
 (pixmap = xcb_generate_id(scrn->conn)),
 scrn->drawable,
 0,
-   scrn->width, scrn->height, buffer->pitch,
+