[PATCH 03/11] renderonly/etnaviv: stop importing resource from renderonly

[Lucas Stach]

Am Montag, den 26.06.2017, 12:37 +0200 schrieb Philipp Zabel:
> On Fri, 2017-06-23 at 17:50 +0200, Lucas Stach wrote:
> > The current way of importing the resource from renderonly after allocation
> > is opaque and is taking away control from the driver, which it needs in
> > order to implement more advanced scenarios, than the simple linear
> > scanout with matching stride alignments.
> > 
> > Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> > ---
> >  src/gallium/auxiliary/renderonly/renderonly.c    | 52 +++++++-----------------
> >  src/gallium/auxiliary/renderonly/renderonly.h    | 20 ++++-----
> >  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c |  8 ++--
> >  src/gallium/drivers/etnaviv/etnaviv_resource.c   | 23 +++++++----
> >  src/gallium/drivers/etnaviv/etnaviv_resource.h   |  5 +++
> >  5 files changed, 49 insertions(+), 59 deletions(-)
> > 
> [...]
> > diff --git a/src/gallium/auxiliary/renderonly/renderonly.h b/src/gallium/auxiliary/renderonly/renderonly.h
> > index 70641c45878a..6a89c29e2ef6 100644
> > --- a/src/gallium/auxiliary/renderonly/renderonly.h
> > +++ b/src/gallium/auxiliary/renderonly/renderonly.h
> > @@ -34,8 +34,6 @@
> >  struct renderonly_scanout {
> >     uint32_t handle;
> >     uint32_t stride;
> > -
> > -   struct pipe_resource *prime;
> >  };
> >  
> >  struct renderonly {
> > @@ -59,7 +57,8 @@ struct renderonly {
> >      *   to be done in flush_resource(..) like a resolve to linear.
> >      */
> >     struct renderonly_scanout *(*create_for_resource)(struct pipe_resource *rsc,
> > -                                                     struct renderonly *ro);
> > +                                                     struct renderonly *ro,
> > +                                                     struct winsys_handle *out_handle);
> >     int kms_fd;
> >     int gpu_fd;
> >  };
> > @@ -68,14 +67,13 @@ struct renderonly *
> >  renderonly_dup(const struct renderonly *ro);
> >  
> >  static inline struct renderonly_scanout *
> > -renderonly_scanout_for_resource(struct pipe_resource *rsc, struct renderonly *ro)
> > +renderonly_scanout_for_resource(struct pipe_resource *rsc,
> > +                                struct renderonly *ro,
> > +                                struct winsys_handle *out_handle)
> >  {
> > -   return ro->create_for_resource(rsc, ro);
> > +   return ro->create_for_resource(rsc, ro, out_handle);
> >  }
> 
> This changes the signature for renderonly_scanout_for_resource, which is
> also called at:
> 
> src/gallium/drivers/vc4/vc4_resource.c:601:                        renderonly_scanout_for_resource(prsc, screen->ro);
> 
> since commit 7029ec05e2c7 ("gallium: Add renderonly-based support for
> pl111+vc4.").
> 
> > -struct renderonly_scanout *
> > -renderonly_scanout_for_prime(struct pipe_resource *rsc, struct renderonly *ro);
> > -
> >  void
> >  renderonly_scanout_destroy(struct renderonly_scanout *scanout,
> >  			   struct renderonly *ro);
> [...]
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index 97e0a15597fa..c6e7e98837b6 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -214,8 +214,20 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned layout,
> >     rsc->bo = bo;
> >     rsc->ts_bo = 0; /* TS is only created when first bound to surface */
> >  
> > -   if (templat->bind & PIPE_BIND_SCANOUT)
> > -      rsc->scanout = renderonly_scanout_for_resource(&rsc->base, screen->ro);
> > +   if (templat->bind & PIPE_BIND_SCANOUT) {
> > +      struct winsys_handle handle;
> > +      rsc->scanout = renderonly_scanout_for_resource(&rsc->base, screen->ro,
> > +                                                     &handle);
> > +      if (!rsc->scanout)
> > +         goto free_rsc;
> > +
> > +      rsc->external = pscreen->resource_from_handle(pscreen, &rsc->base,
> > +                                                    &handle,
> > +                                                    PIPE_HANDLE_USAGE_WRITE);
> > +      close(handle.handle);
> 
> Is the handle guaranteed to be DRM_API_HANDLE_TYPE_FD at this point?

It's not guaranteed, but it's the only type that makes sense as
renderonly_scanout_for_resource allocates from a different device. I'll
add an assert, which should be enough to catch any changes in that area.

Regards,
Lucas