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


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