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