Michel Dänzer wrote:
On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@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 <mic...@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....@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.
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.
Pure luck noticing this because I haven't tested modesetting driver for
ages, but -
These patches also break full screen vdpau playback when using that.
Result is a screen of mostly junk with a hint of the vid - looks like
when direct scan out fails on wayland due to tiling mismatch.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
