On Sat, Dec 01, 2012 at 07:08:12PM +0200, Terje Bergström wrote: > On 01.12.2012 16:45, Thierry Reding wrote: > > I did some prototyping on how a libdrm API could look like a few weeks > > back. I should clean the patches up some and push them to a public > > repository or to the mailing lists for review. > > Ok. Sorry about the delay - I recently learned I need separate > permission for user space contribution, so I'm pushing to get that > permission. Oh dear. Doesn't sound like fun. =) > > There isn't actually much more than a bit of framework along with two > > IOCTLs that allow creating and looking up a Tegra-specific GEM. The > > related kernel patches aren't available anywhere since I didn't deem > > them ready yet. At that time I wasn't even sure if we'd need special > > allocations other than what the dumb BO infrastructure provides. They > > implement some parts of what you've implemented in this series as well, > > with some slight differences. > > Ok, the BO infra is still under flux as we're designing the best place > and work split. Yes, I've put the prototype under a --enable-tegra-experimental-api switch, which has been used in the past for helpers that weren't finalized yet. > > While I can't find the quote right now, I seem to remember that you said > > at some point that you were planning on adding some 2D acceleration bits > > to libdrm. I don't think that's the right place. That code should rather > > go into the DDX. libdrm should instead provide a thin layer on top of > > the DRM IOCTLs to manage buffers and submit command streams. I hope I > > can finish the cleanup of my libdrm patches over the weekend and push > > them out so this may become clearer. Maybe I can even get the > > corresponding kernel patches pushed out. > > Yep, that's exactly what I actually posed as a question in one of the > earlier mails. We also agree that 2D bits should not stay in libdrm. > That's why we've kept the 2D bits design-wise separate from the host1x > stream generation. > > We don't yet have any other place to put 2D functions in, so we'll > probably post them as part of patch series to libdrm. We'll just add a > disclaimer that the 2D code won't remain in libdrm, and wanted to get > the code out to review as a code example. We can put the 2D code either > to a separate library or to DDX, whichever is preferred. FWIW, I've done some work on an initial DDX, which is basically a fork of xf86-video-modesetting rebranded and with some cleanup like ripping out the PCI support. I wanted to do some testing before pushing it out and I think I can get that done on Monday. Posting the code early is exactly the right thing to do. We still have to figure out quite a number of things and we can always move code between the various components of the whole stack. > The host1x command stream generation would still remain in libdrm. That > seems to be the pattern with other hardware. Yes, I fully agree. Thierry
Attachment:
pgpUo_Wy4uAoI.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
