Kristian Høgsberg wrote: > On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >> Dave Airlie wrote: >> >> > > cheers, >> >> > > Kristian >> >> > > >> >> > Kristian, >> >> > This is OK with me. It will add an extra malloc / free for every >> >> buffer >> >> > object creation / destruction, >> >> > but will make it easier to maintain in the future, (and we can >> get rid >> >> > of the padding for future expansion). >> >> >> >> Exactly, I took out the pad fields in the patch. I think it's a >> >> reasonable tradeoff, since we have a library abstraction barrier here >> >> and the objects aren't tiny to begin with. >> > >> > I can't see any problems with this, who has the time to do it? I'm up >> > the walls with real life.. >> > >> Same here. >> However, we don't strictly need to change the libdrm user-space >> interface right now. >> >> If we focus on getting the kernel TTM code in shape at this point, we >> can change libdrm at a later point, bumping its >> major version. The dl code should automatically load the correct version >> so we won't really have to bother about the next big incompatibility. > > True. And if we bump libdrm major version, we can drop the hash table > and skip lists too. With DRI interface changes, I moved the hash > table implementation into libGL, the only place it's used. > > Kristian Aargh. :) It's used in the XvMC drivers for DRI drawable tracking (At least VIA), although one can argue whether it really belongs in libdrm.
/Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
