[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
> <nayan26deshmukh at gmail.com> wrote:
>> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss <adf.lists at gmail.com> 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.
>>>
>>
>> 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.