[Mesa-dev] [PATCH 1/2] nouveau: Add basic memory object support

[Miguel Angel Vico]

On Thu, 21 Jun 2018 22:09:14 -0400
Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> Hi Miguel,
> 
> Preface: I know little about this ext, so feel free to educate me on
> the wrongness of my thinking.
> 
> On Thu, Jun 21, 2018 at 10:01 PM, Miguel A. Vico <mvicomoya at nvidia.com> wrote:
> > Add memory object support for nvc0 and nv50
> >
> > Signed-off-by: Miguel A Vico Moya <mvicomoya at nvidia.com>
> > ---
> >  .../drivers/nouveau/nv50/nv50_miptree.c       | 49 +++++++++++++----
> >  .../drivers/nouveau/nv50/nv50_resource.c      | 52 +++++++++++++++++++
> >  .../drivers/nouveau/nv50/nv50_resource.h      | 33 ++++++++++++
> >  .../drivers/nouveau/nvc0/nvc0_resource.c      | 22 ++++++++
> >  4 files changed, 146 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> > index f2e304fde6..91007d3dac 100644
> > --- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> > +++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> > @@ -397,13 +397,13 @@ nv50_miptree_create(struct pipe_screen *pscreen,
> >     return pt;
> >  }
> >
> > -struct pipe_resource *
> > -nv50_miptree_from_handle(struct pipe_screen *pscreen,
> > -                         const struct pipe_resource *templ,
> > -                         struct winsys_handle *whandle)
> > +static struct pipe_resource *
> > +nv50_miptree_from_bo(struct pipe_screen *pscreen,
> > +                     const struct pipe_resource *templ,
> > +                     struct nouveau_bo *bo,
> > +                     uint32_t stride)
> >  {
> >     struct nv50_miptree *mt;
> > -   unsigned stride;
> >
> >     /* only supports 2D, non-mipmapped textures for the moment */  
> 
> Won't this be a drag, since you're supposed to be able to "place" 3d
> textures, as well as mip-mapped ones?
> 
> The reason I haven't looked at doing VK for nouveau yet is that the
> nouveau kernel API does not allow explicit userspace-side VA
> management, which would be required to allow something like this. I
> believe it would also be required to implement this GL extension. Feel
> free to correct my thinking.

My understanding is that EXT_external_objects itself only presents a
generic interface for applications to feed external memory handles to
OpenGL. It doesn't specify what properties those handles need to
satisfy, or whether the memory comes from user-space or any other
driver component. It is up for specific extensions to define new memory
objects, their properties, and how they can be imported/exported.

As I understand it, the initial motivation for putting together this
extension was indeed Vulkan-OpenGL interoperability, but it is not
limited to that.

This initial implementation of the extension adds the logic to allow
applications to feed opaque handles to OpenGL, but there's no API that
can create compatible opaque handles for the nouveau driver yet.

Just to add a bit more context, here's a prototype of an extension
defining one of such handles:

  https://gitlab.freedesktop.org/mvicomoya/mesa/tree/wip/NVX_unix_allocator_import

It is used by the the kmscube prototype that uses the generic allocator
to allocate buffers:

  https://gitlab.freedesktop.org/allocator/kmscube/merge_requests/1

And EXT_external_objects is just a pre-requisite for that.

Thanks.

> 
> Cheers,
> 
>   -ilia


-- 
Miguel