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

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