[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 <adf.lists at gmail.com> 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 <michel at daenzer.net>
>>> wrote:
>>>>
>>>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>>>>
>>>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <michel at daenzer.net>
>>>>> 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 <leo.liu at amd.com>
>>>>>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshmukh at gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> Acked-by: Christian König <christian.koenig at amd.com>.
>>>>>>>>
>>>>>>>> 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.
>