Re: [RFC v2 0/8] Support for Tegra 2D hardware

[Thierry Reding <thierry.reding@avionic-design.de>]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

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 #2: Type: application/pgp-signature, Size: 836 bytes --]