On Tue, Mar 25, 2003 at 11:21:22PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: > >>The idea is that the X server and the 3D driver can use the same memory > >>manager for off-screen memory. That way pixmap cache, textures, and > >>vertex buffers all get managed in the "same" way and share ALL of off > >>screen memory. > > > > Yes, and existing core X server APIs allow that. > > How can it do that with direct rendering?
Well, okay, there needs to be a little extra handholding between server and client. So, you add a GLX_dri_reserve_mem extension or something that reserves video memory by proxy. Or do it in some more direct fashion, bypassing GLX protocol overhead if you prefer, but still letting the GLX module on the server reserve it cleanly through the server interfaces. That's the clean way to do it, even if it requires more coding on the DRI side. For non-video (ie AGP) memory, the issue isnt relevant, since the client can do the reservation through the drm kernel driver directly, I believe. >? Even worse, if the 3D driver code "lives" in Mesa CVS and the > core server code lives in XFree86 CVS, we would have the same code > living in two different trees! You only have duplicate code for this, if you code it "wrong" :-> Duplicate code is usually one of the basic signs of "the code needs a redesign" Video mem is a core X server resource, and should be reserved through the core server, always. It would be different if there were no core api for allocationg video ram. But there is. So use it. [okay, the docs suck. but it's still there] ------------------------------------------------------- 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
