On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <mvicom...@nvidia.com> wrote:
> Inline. > > On Wed, 20 Dec 2017 11:54:10 -0800 > Kristian Høgsberg <hoegsb...@gmail.com> wrote: > > > On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > > > Since this also involves the kernel let's add dri-devel ... > > Yeah, I forgot. Thanks Daniel! > > > > > > > On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico < > mvicom...@nvidia.com> wrote: > > >> Hi all, > > >> > > >> As many of you already know, I've been working with James Jones on the > > >> Generic Device Allocator project lately. He started a discussion > thread > > >> some weeks ago seeking feedback on the current prototype of the > library > > >> and advice on how to move all this forward, from a prototype stage to > > >> production. For further reference, see: > > >> > > >> https://lists.freedesktop.org/archives/mesa-dev/2017- > November/177632.html > > >> > > >> From the thread above, we came up with very interesting high level > > >> design ideas for one of the currently missing parts in the library: > > >> Usage transitions. That's something I'll personally work on during the > > >> following weeks. > > >> > > >> > > >> In the meantime, I've been working on putting together an open source > > >> implementation of the allocator mechanisms using the Nouveau driver > for > > >> all to be able to play with. > > >> > > >> Below I'm seeking feedback on a bunch of changes I had to make to > > >> different components of the graphics stack: > > >> > > >> ** Allocator ** > > >> > > >> An allocator driver implementation on top of Nouveau. The current > > >> implementation only handles pitch linear layouts, but that's enough > > >> to have the kmscube port working using the allocator and Nouveau > > >> drivers. > > >> > > >> You can pull these changes from > > >> > > >> https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/ > nouveau-driver > > >> > > >> ** Mesa ** > > >> > > >> James's kmscube port to use the allocator relies on the > > >> EXT_external_objects extension to import allocator allocations to > > >> OpenGL as a texture object. However, the Nouveau implementation of > > >> these mechanisms is missing in Mesa, so I went ahead and added them. > > >> > > >> You can pull these changes from > > >> > > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_ > external_objects-nouveau > > >> > > >> Also, James's kmscube port uses the NVX_unix_allocator_import > > >> extension to attach allocator metadata to texture objects so the > > >> driver knows how to deal with the imported memory. > > >> > > >> Note that there isn't a formal spec for this extension yet. For now, > > >> it just serves as an experimental mechanism to import allocator > > >> memory in OpenGL, and attach metadata to texture objects. > > >> > > >> You can pull these changes (written on top of the above) from: > > >> > > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_ > unix_allocator_import > > >> > > >> ** kmscube ** > > >> > > >> Mostly minor fixes and improvements on top of James's port to use > the > > >> allocator. Main thing is the allocator initialization path will use > > >> EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported > > >> by the underlying EGL implementation. > > >> > > >> You can pull these changes from: > > >> > > >> https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/ > allocator-nouveau > > >> > > >> > > >> With all the above you should be able to get kmscube working using the > > >> allocator on top of the Nouveau driver. > > >> > > >> > > >> Another of the missing pieces before we can move this to production is > > >> importing allocations to DRM FB objects. This is probably one of the > > >> most sensitive parts of the project as it requires > modification/addition > > >> of kernel driver interfaces. > > >> > > >> At XDC2017, James had several hallway conversations with several > people > > >> about this, all having different opinions. I'd like to take this > > >> opportunity to also start a discussion about what's the best option to > > >> create a path to get allocator allocations added as DRM FB objects. > > >> > > >> These are the few options we've considered to start with: > > >> > > >> A) Have vendor-private ioctls to set properties on GEM objects that > > >> are inherited by the FB objects. This is how our (NVIDIA) desktop > > >> DRM driver currently works. This would require every vendor to > add > > >> their own ioctl to process allocator metadata, but the metadata > is > > >> actually a vendor-agnostic object more like DRM modifiers. We'd > > >> like to come up with a vendor-agnostic solutions that can be > > >> integrated to core DRM. > > >> > > >> B) Add a new drmModeAddFBWithMetadata() command that takes allocator > > >> metadata blobs for each plane of the FB. Some people in the > > >> community have mentioned this is their preferred design. This, > > >> however, means we'd have to go through the exercise of adding > > >> another metadata mechanism to the whole graphics stack. > > >> > > >> C) Shove allocator metadata into DRM by defining it to be a separate > > >> plane in the image, and using the existing DRM modifiers > mechanism > > >> to indicate there is another plane for each "real" plane added. > It > > >> isn't clear how this scales to surfaces that already need several > > >> planes, but there are some people that see this as the only way > > >> forward. Also, we would have to create a separate GEM buffer for > > >> the metadatada itself, which seems excessive. > > >> > > >> We personally like option (B) better, and have already started to > > >> prototype the new path (which is actually very similar to the > > >> drmModeAddFB2() one). You can take a look at the new interfaces here: > > >> > > >> https://github.com/mvicomoya/linux/tree/wip/mvicomoya/drm_ > addfb_with_metadata__4.14-rc8 > > >> > > >> There may be other options that haven't been explored yet that could > be > > >> a better choice than the above, so any suggestion will be greatly > > >> appreciated. > > > > > > What kind of metadata are we talking about here? Addfb has tons of > > > stuff already that's "metadata". The only thing I've spotted is > > > PITCH_ALIGNMENT, which is maybe something we want drm drivers to tell > > > userspace, but definitely not something addfb ever needs. addfb only > > > needs the resulting pitch that we actually allocated (and might decide > > > it doesn't like that, but that's a different issue). > > Sorry I failed to make it clearer. Metadata here refers to all > allocation parameters the generic allocator was given to allocate > memory. That currently means the final capability set used for > the allocation, including all constraints (such as memory alignment, > pitch alignment, and others) and capabilities, describing allocation > properties like tiling formats, compression, and such. > > > > > > > And since there's no patches for nouveau itself I can't really say > > > anything beyond that. > > I can work on implementing these interfaces for nouveau, maybe > partially, if that's going to help. I just thought it'd be better to > first start a discussion on what would be the right way to pass > allocator metadata to display drivers before starting to seriously > implement any of the proposed options. > > > > > I'd like to see concrete examples of actual display controllers > > supporting more format layouts than what can be specified with a 64 > > bit modifier. > > The main problem is our tiling and other metadata parameters can't > generally fit in a modifier, so we find passing a blob of metadata a > more suitable mechanism. > I understand that you may have n knobs with a total of more than a total of 56 bits that configure your tiling/swizzling for color buffers. What I don't buy is that you need all those combinations when passing buffers around between codecs, cameras and display controllers. Even if you're sharing between the same 3D drivers in different processes, I expect just locking down, say, 64 different combinations (you can add more over time) and assigning each a modifier would be sufficient. I doubt you'd extract meaningful performance gains from going all the way to a blob. If you want us the redesign KMS and the rest of the eco system around blobs instead of the modifiers that are now moderately pervasive, you have to justify it a little better than just "we didn't find it suitable". Kristian > Thanks. > > > > > Kristian > > > > > -Daniel > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > > mesa-dev mailing list > > mesa-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > -- > Miguel > > >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
