On 10/09/16 12:49 AM, Nayan Deshmukh wrote:
> In case of prime when rendering is done on GPU other then the
> server GPU, use a seprate linear buffer for each back buffer
> which will be displayed using present extension.
>
> v2: Use a seprate linear buffer for each back buffer (Michel)
> v3: change variable names and fix coding style (Leo and Emil)
>
> Signed-off-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
[...]
> @@ -226,8 +232,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> goto close_fd;
>
> memset(&templ, 0, sizeof(templ));
> - templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
> - PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> + templ.bind = PIPE_BIND_RENDER_TARGET;
I suspect PIPE_BIND_SAMPLER_VIEW is needed here as well, for when
resource_copy_region ends up being a textured draw operation.
> @@ -485,6 +513,16 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
> return;
> }
>
> + if (scrn->is_different_gpu) {
> + u_box_origin_2d(scrn->width, scrn->height, &src_box);
> + scrn->pipe->resource_copy_region(scrn->pipe,
> + back->linear_texture,
> + 0, 0, 0, 0,
> + back->texture,
> + 0, &src_box);
> +
> + scrn->pipe->flush(scrn->pipe, NULL, 0);
> + }
> xshmfence_reset(back->shm_fence);
> back->busy = true;
>
> @@ -699,6 +733,9 @@ vl_dri3_screen_create(Display *display, int screen)
> if (!scrn->base.pscreen)
> goto release_pipe;
>
> + scrn->pipe = scrn->base.pscreen->context_create(scrn->base.pscreen,
> + &scrn->base, 0);
Hmm. AFAICT the callers of vl_dri3_flush_frontbuffer only flush their
own context after calling it. Is there any guarantee that the rendering
to back->texture is flushed before the resource_copy_region call above?
Either the callers need to be changed to flush before calling
flush_frontbuffer, or the flush_frontbuffer hook might need to grow an
optional context parameter for this, similar to resource_get_handle.
BTW, while looking into this, I noticed that vl_dri3_screen_create
overrides the pipe_screen flush_frontbuffer hook with
vl_dri3_flush_frontbuffer. That's a little ugly and would probably break
with drivers whose flush_frontbuffer hook actually does something. At
the very least, the vl_winsys_dri3.c code should save any previous hook
and call down to it from vl_dri3_flush_frontbuffer.
--
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
