On Wed, 2008-08-20 at 04:19 +0100, Dave Airlie wrote: > > It falls back gracefully though (I think TTM did as well, though this API > > is > > smaller in that it doesn't pass a huge gob of flags around), so if we think > > the libdrm bufmgr interface is stable there should be no problem. > > The problem is I am not that happy that the bufmgr interface is stable, > its been changed quite a bit during GEM dev, and I forsee more changes to > it to support other users... > > You missed the point it fails back gracefully at *runtime*, and if we do > end up with a slight change to the interface in the kernel later we have > code that could wait in hiding for the bits to be enabled in the kernel.
On the subject of bufmgr interface stability, I'd wanted to put it in
libdrm because I thought others were going to be using it, it's small,
and we've got at least 3 components that want to use it
text data bss dec hex filename
9648 0 0 9648 25b0 intel_bufmgr_fake.o (ex
/home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a)
6328 0 0 6328 18b8 intel_bufmgr_gem.o (ex
/home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a)
1681 0 0 1681 691 mm.o (ex
/home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a)
726 0 0 726 2d6
/home/anholt/src/drm/libdrm/.libs/dri_bufmgr.o
18383 0 0 18383 47cf (TOTALS)
But last I heard, it looks like it's really too specific for dri_bufmgr
to be usefully shared between drivers. At that point, it seems like
libdrm is the wrong place for it, particularly if we're concerned about
wanting to do ABI incompatible bumps (as we've done several times
already). Should I move it out to a libdrm_intel.so and intel_bufmgr.h,
so that I'm not burdening other people with my API and ABI issues?
> > Don't we keep saying "libdrm is the interface" these days anyway? So if
> > that
> > part is sane we should just release what's in libdrm master now or soon.
> > But
> > maybe I'm forgetting (ignorance is bliss) some aspect of the pain we had
> > with
> > TTM...
>
> for instance there are two direct GEM ioctls in the intel mesa code,
> libdrm currently publishes files it shouldn't, the plan is to build libdrm
> against kernel published files, however these files aren't in the kernel
> so I can release a libdrm against them. As I said on irc, you build a
> house (even a house of cards) from the bottom, doing it in reverse is not
> a good plan. There is no point having released userspace bits with no
> kernel to support them.
>
> So there will not be a libdrm release with any of this stuff in it before
> the upstream bits are in the kernel. We tried that with TTM, and we had
> lots of pain.
I can agree with that summary -- "until the kernel accepts the
interface, don't release". It's kind of a pain, but it's our fault for
the development model we've had. Hopefully things get better.
One thing I'd like to do is split the libdrm userspace component from
the drm external kernel modules tree -- /git/mesa/libdrm perhaps. Then
we don't have to worry about whether the driver can be built on specific
kernels when we're just trying to get the userland component ready.
I suppose the alternative would be for us to just back out the GEM stuff
in the kernel module part and leave things they were so that
external-tree developers can continue and those of us that need to
integrated with the kernel work just in kernel trees
Any opinions?
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
