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.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to