Hi Christian,
Am Freitag, den 28.12.2018, 11:04 +0100 schrieb Christian Gmeiner:
> Am Di., 18. Dez. 2018 um 19:09 Uhr schrieb Lucas Stach
> <l.st...@pengutronix.de>:
> >
> > We try to avoid sharing all resources with KMS side of renderonly, as this
> > adds some overhead that isn't really needed for most resources. If
> > someone tries to validate a resource for scanout, this is a good indication
> > that the sharing with the KMS side is actually needed.
> >
> > > > Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
> > ---
> > .../drivers/etnaviv/etnaviv_resource.c | 22 +++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index c00912880309..cd846e3ae36e 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -624,6 +624,27 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
> > }
> > }
> >
> > +static bool
> > +etna_check_resource_capability(struct pipe_screen *pscreen,
> > + struct pipe_resource *prsc,
> > + unsigned bind)
> > +{
> > + struct etna_screen *screen = etna_screen(pscreen);
> > + struct etna_resource *rsc = etna_resource(prsc);
> > +
> > + if ((bind & PIPE_BIND_LINEAR) && rsc->layout != ETNA_LAYOUT_LINEAR)
> > + return false;
> > +
> > + if ((bind & PIPE_BIND_SCANOUT) && !rsc->scanout) {
> > + rsc->scanout = renderonly_create_gpu_import_for_resource(prsc,
> > screen->ro,
> > + NULL);
>
> Can you explain me why the
> renderonly_create_gpu_import_for_resource(..) call ends up here? Are
> there really any cases where !rsc->scanout? I looked at the relevant
> code parts and I have the feeling
> the renderonly_create_gpu_import_for_resource(..) call happens much
> earlier in the call chain. I could be
> wrong as I am running out of coffee right now :)
There is one very relevant use-case where we end up with no scanout
resource: dma-buf import on the compositor side with Wayland. On
i.MX6qp we get a client buffer that is perfectly fine for putting
directly on a imx-drm on a plane.
When we import the buffer through GBM we end up with a etnaviv resource
without a scanout handle. GBM will make sure to validate the imported
buffer for scanout before trying to export the KMS handle though. So we
can construct the scanout handle at that point to allow the compositor
to push the client buffer directly onto the plane, skipping the
composition step in some cases.
Regards,
Lucas
> > + if (!rsc->scanout)
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +
> > void
> > etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
> > enum etna_resource_status status)
> > @@ -667,4 +688,5 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
> > pscreen->resource_get_handle = etna_resource_get_handle;
> > pscreen->resource_changed = etna_resource_changed;
> > pscreen->resource_destroy = etna_resource_destroy;
> > + pscreen->check_resource_capability = etna_check_resource_capability;
> > }
> > --
> > 2.19.1
> >
> > _______________________________________________
> > etnaviv mailing list
> > etna...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/etnaviv
>
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
