From: Matt S. <so...@so...> - 2005-11-11 23:08:36
|
>I go back and forth on this. My concern is that the DRI protocol really = =0D=0A>shouldn't be user visible at all. In fact I'm largely of the opinion= that =0D=0A>the DRI protocol was a mistake. Almost all of it should have b= een either =0D=0A>inferred from existing GLX protocol (drawable and context= ops) or added as =0D=0A>GLX extensions as an implementation detail (driver= name and authentication).=0D=0A=0D=0AThe protocol isn't user visible. Just= as the GLX wire protocol isn't user visible, but anyone writing a=0D=0ADRI= client library (writing libGL or libXvMC) needs access to that protocol an= d there is no=0D=0Areason to re-write it each time... or for each library t= o have a local copy of the same files.=0D=0AA library only makes the presen= t day reality easier.=0D=0A=0D=0AThe only parts of DRI that are at all usef= ul to me are the startup, find your drm driver, and authenticate=0D=0Aparts= . Those have real value in sharing because they really need to be done righ= t. If you want to tear=0D=0Athose away from the other things that are reall= y rendering implementation specific then thats fine with=0D=0Ame (I have no= use for the other bits anyway)=0D=0A=0D=0A>The bloat argument doesn't so m= uch fly if everything else is already linking =0D=0A>against this one copy.= =0D=0A=0D=0AThere really is no concern if you're using shared libs. Agreed.= =0D=0A=0D=0A>I think you misunderstand the memory manager's job. It's expli= citly for =0D=0A>managing memory in the presence of more than one process c= ompeting for it. =0D=0A>The whole _point_ is that the X server, the GL driv= ers, the XvMC drivers, and =0D=0A>whatever else all have a consistent view = of card memory and the ability to =0D=0A>grab as much of it as they need (i= nstead of the current hack job where most =0D=0A>drivers just split offscre= en memory in two and hand half to the DDX and have =0D=0A>to the DRI client= s).=0D=0A>=0D=0A>If you don't think you need this for your embedded platfor= m, then, uh, why are =0D=0A>you using X.=0D=0A=0D=0AI understand completely= . I fully agree that there needs to be one memory manager=0D=0Afor everyone= to use... and I already have one. So as long as the libdrm memory manager= =0D=0Adoesn't start becoming integral to making libdrm work, we can all con= tinue to benifit=0D=0Afrom the library.=0D=0A=0D=0A>Also, I expect the memo= ry management layer in libdrm to be a pretty thin =0D=0A>wrapper around the= ioctls exported by the kernel. =0D=0A=0D=0Aoh, I see. I didn't realize tha= t you were going kernel-side with the actual manager. So=0D=0Aagain... thes= e ioctls will be optional right? You can still make a drm driver without ex= posing=0D=0Adrm memory manager functionality?=0D=0A=0D=0A-Matt=0D=0A=0D=0A |