Hi Michel,
On Mon, Sep 12, 2016 at 7:02 PM, Leo Liu <leo....@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 <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.
>>
>>
>> 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.
>>
>>
>>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
