On 09/12/2016 04:31 AM, Michel Dänzer wrote:
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?
No.
ST will call the flush that is only for copying to back buffer for
presentation.
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 inherited from DRI2.
Regards,
Leo
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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
