On Friday 11 November 2005 14:22, Matt Sottek wrote: > 1) Is libdrm intended to be staticly linked with a libGL, libXvMC etc. Or > are you invisioning a dynamic library available on all systems?
Intended to be dynamic. Any layer that needs to talk to the DRM driver
(server, libGL, libXvMC...) should be doing so through a single copy of
libdrm.
> 2) Can you please make it c++ safe. (Haven't looked at 1.0 but we needed
> modifications) A quick check reveals things like bufs.virt in xf86drm.c and
> the need for extern "C" { around the function prototypes.
Certainly. Patches would definitely be welcome.
> 3) What about libXF86DRI? To make a DRI client you need libdrm and a
> hypothetical libXF86DRI to get the functions such as XF86DRIOpenConnection.
> Clearly you'd want to rename the functions to something like
> XDRIOpenConnection(), but getting a library that can be linked by other
> clients would be nice.
I go back and forth on this. My concern is that the DRI protocol really
shouldn't be user visible at all. In fact I'm largely of the opinion that
the DRI protocol was a mistake. Almost all of it should have been either
inferred from existing GLX protocol (drawable and context ops) or added as
GLX extensions as an implementation detail (driver name and authentication).
> 4) Any way I can persuade you to NOT put the memory manager in libdrm?
Highly unlikely.
> Perhaps another little library, released from the same place but not really
> linked together. I have a need for libdrm but I have no use for your memory
> manager and it seems like a lot of weight that I don't want to carry.
The bloat argument doesn't so much fly if everything else is already linking
against this one copy.
> It also seems a bit misplaced to me. The DRI and DRM protocols are things of
> general use that anyone using the DRI would need. The memory manager is a
> helper so that code can be shared between drivers (your drivers), but is
> not a required component that would be used by other libGL implementations
> etc.
I think you misunderstand the memory manager's job. It's explicitly for
managing memory in the presence of more than one process competing for it.
The whole _point_ is that the X server, the GL drivers, the XvMC drivers, and
whatever else all have a consistent view of card memory and the ability to
grab as much of it as they need (instead of the current hack job where most
drivers just split offscreen memory in two and hand half to the DDX and have
to the DRI clients).
If you don't think you need this for your embedded platform, then, uh, why are
you using X.
Also, I expect the memory management layer in libdrm to be a pretty thin
wrapper around the ioctls exported by the kernel. Equivalent in size roughly
to the skip list code (which none of the open drivers use last I checked, and
I doubt yours does either). So if you really don't want that bloat, look to
the kernel to disable it.
The whole purpose of libdrm's existance is to be the one point for wrapping
the interface to the kernel. That includes memory management, so the drmMM
API belongs in libdrm. As a practical matter, if I'm given the choice
between maintaining two libdrm ABIs - where the smaller one exists solely to
make life slightly easier for a closed-source driver - and maintaining only
one ABI, I'm going to choose to maintain only one. People who choose to keep
their drivers closed have chosen to make their lives hard. I'm not going to
break closed drivers without good reason, but I'm also not going to make poor
engineering decisions based on their needs.
Seriously. The API being proposed is all of 11 functions. The libdrm API
averages about 120 bytes per function. Even if the memory management API is
three times that heavy, that's still less than a page. You'd save more by
building your driver with -fvisibility=hidden.
- ajax
pgp90qfxze6KA.pgp
Description: PGP signature
