On Tue, Jan 10, 2017 at 12:56 PM, Andy Furniss <adf.li...@gmail.com> wrote: > Alex Deucher wrote: >> >> On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh >> <nayan26deshm...@gmail.com> wrote: >>> >>> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss <adf.li...@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....@amd.com> >>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com> >>>>> >>>>> >>>>> >>>>> Acked-by: Christian König <christian.koe...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
