[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers(v4)

[Alex Deucher]

On Tue, Jan 10, 2017 at 12:56 PM, Andy Furniss <adf.lists at gmail.com> wrote:
> 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.
>

Thanks for clarifying.  I didn't realize the tearing and performance
were intertwined.

Alex