Re: Questions on libdrm Future

[Matt Sottek]

>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).

The protocol isn't user visible. Just as the GLX wire protocol isn't user visible, but anyone writing a
DRI client library (writing libGL or libXvMC) needs access to that protocol and there is no
reason to re-write it each time... or for each library to have a local copy of the same files.
A library only makes the present day reality easier.

The only parts of DRI that are at all useful to me are the startup, find your drm driver, and authenticate
parts. Those have real value in sharing because they really need to be done right. If you want to tear
those away from the other things that are really rendering implementation specific then thats fine with
me (I have no use for the other bits anyway)

>The bloat argument doesn't so much fly if everything else is already linking
>against this one copy.

There really is no concern if you're using shared libs. Agreed.

>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.

I understand completely. I fully agree that there needs to be one memory manager
for everyone to use... and I already have one. So as long as the libdrm memory manager
doesn't start becoming integral to making libdrm work, we can all continue to benifit
from the library.

>Also, I expect the memory management layer in libdrm to be a pretty thin
>wrapper around the ioctls exported by the kernel.

oh, I see. I didn't realize that you were going kernel-side with the actual manager. So
again... these ioctls will be optional right? You can still make a drm driver without exposing
drm memory manager functionality?

-Matt