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

[Nayan Deshmukh]

Hi Michel,


On Mon, Sep 12, 2016 at 7:02 PM, Leo Liu <leo.liu at amd.com> wrote:

>
>
> 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.
>>
>>
>> I will add this.

> @@ -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_cr
>>> eate(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.
>>
>>
>> vl_winsys_dri3 is used by vdpau and va, so I can make them flush before
calling
flush_frontbuffer. Adding a context argument will involve changes to a
lot of other files.

Regards,
Nayan.


> 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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160912/ec1bb52a/attachment.html>