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?
It will probably depend on the way drivers handle PIPE_BIND_SCANOUT. Regards, Nayan. > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
