[Mesa-dev] [PATCH v3] vl/dri3: handle the case of different GPU

[Michel Dänzer]

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 <nayan26deshmukh at 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