[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 <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.