Re: Questions on libdrm Future

[Adam J. <aj...@nw...>]

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=20
(server, libGL, libXvMC...) should be doing so through a single copy of=20
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 a=
nd
> 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=20
> hypothetical libXF86DRI to get the functions such as XF86DRIOpenConnectio=
n. =20
> Clearly you'd want to rename the functions to something like=20
> XDRIOpenConnection(), but getting a library that can be linked by other
> clients would be nice.=20

I go back and forth on this.  My concern is that the DRI protocol really=20
shouldn't be user visible at all.  In fact I'm largely of the opinion that=
=20
the DRI protocol was a mistake.  Almost all of it should have been either=20
inferred from existing GLX protocol (drawable and context ops) or added as=
=20
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?=20

Highly unlikely.

> Perhaps another little library, released from the same place but not real=
ly
> linked together. I have a need for libdrm but I have no use for your memo=
ry
> 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 linkin=
g=20
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=20
managing memory in the presence of more than one process competing for it. =
=20
The whole _point_ is that the X server, the GL drivers, the XvMC drivers, a=
nd=20
whatever else all have a consistent view of card memory and the ability to=
=20
grab as much of it as they need (instead of the current hack job where most=
=20
drivers just split offscreen memory in two and hand half to the DDX and hav=
e=20
to the DRI clients).

If you don't think you need this for your embedded platform, then, uh, why =
are=20
you using X.

Also, I expect the memory management layer in libdrm to be a pretty thin=20
wrapper around the ioctls exported by the kernel.  Equivalent in size rough=
ly=20
to the skip list code (which none of the open drivers use last I checked, a=
nd=20
I doubt yours does either).  So if you really don't want that bloat, look t=
o=20
the kernel to disable it.

The whole purpose of libdrm's existance is to be the one point for wrapping=
=20
the interface to the kernel.  That includes memory management, so the drmMM=
=20
API belongs in libdrm.  As a practical matter, if I'm given the choice=20
between maintaining two libdrm ABIs - where the smaller one exists solely t=
o=20
make life slightly easier for a closed-source driver - and maintaining only=
=20
one ABI, I'm going to choose to maintain only one.  People who choose to ke=
ep=20
their drivers closed have chosen to make their lives hard.  I'm not going t=
o=20
break closed drivers without good reason, but I'm also not going to make po=
or=20
engineering decisions based on their needs.

Seriously.  The API being proposed is all of 11 functions.  The libdrm API=
=20
averages about 120 bytes per function.  Even if the memory management API i=
s=20
three times that heavy, that's still less than a page.  You'd save more by=
=20
building your driver with -fvisibility=3Dhidden.

=2D ajax