On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote: > Philip Brown wrote: > >So since it is orthogonal, you should have no objections to lowest-level > >allocation of video memory being done by GLX calling xf86Allocate > >routines, yes? > >(ie: "leave the X core code alone") > > That is what's currently done. The goal was two fold. One (very minor, > IMO) goal was to allow the pixmap cache to cooperate with the texture > cache. The other goal was to allow the amount of memory used by the > front buffer to be dynamic when the screen mode changes. > > >I believe this whole thread started off by references to hacking X server > >code to call DRI extension code. That is what I am arguing against, as > >unneccessary. Extension code should call core code, not the other way > >around (except for API-registered callbacks, of course) > > The way to do that is to reproduce code from the 3D driver in the X > server. The memory management code that is in the 3D driver (for doing > the allocations and communicating with the DRM) really has to be there. > Moving it into the X server would really hurt performance. There's > really only four possible solutions: > > 1. Have the X server call the code in the 3D driver. > 2. Have the 3D driver call the code in the X server. > 3. Have the code exist in both places. > 4. Leave things as they are. > > I'm saying the #2 is unacceptable for performance reasons. You're > saying that #1 unacceptable for software engineering reasons. We're > both saying that #3 is unacceptable for software engineering reasons. > Users are saying #4 is unacceptable for performance reasons. Where does > that leave us?
What about #3, but using a common library, so the same code is linked in in two places ? Friendly, Sven Luther ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
