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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121201192917.GA19348@avionic-0098.adnet.avionic-design.de>
Date:	Sat, 1 Dec 2012 20:29:17 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Terje Bergström <tbergstrom@...dia.com>
Cc:	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 0/8] Support for Tegra 2D hardware

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

Content of type "application/pgp-signature" skipped