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

[Leo Liu]

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 <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?
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.
>
>