On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > 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. > > After reading this I honestly believe that you and I must be talking > about different things. I'm talking about allocating a block of memory > to hold a texture that's going to be read directly by the rendering > hardware. The texture should be kept in directly readable memory > (either on-card or AGP) unless the space is needed by some other operation. > > Not only that, this is an operation that needs to be fast. As fast as > possible, in fact.
Yes, I know that. Sounds like we just didnt get down to discussing the details. Consider the GLX_dri_reserve_mem as equivalent to sbrk() Then have a more local memory allocator for subdividing the large chunk. That's going to be a lot more efficient that relying on the XFree routines to do fine-level memory management anyways. xfree's routines arent really optimized for that sort of thing, I think. > > Right now our memory manager is layered on top of the X memory manager. > [stuff on future texmem ....] Well, great. Sounds like we're actually talking about the same thing then. It's just a matter of what granularity you call the X server for requesting memory. Currently, I'm guessing its a matter of [pseudocode] size=FindAllFreeMem(); xallocmem(size); Wheres what would be nicer to the server, while still preserving local speed, would probably be to alloc X memory in 2 megabyte chunks, or something like that, and then use the layered local memory manager for those large chunk(s). [some reasonable fraction of FindAllFreeMem(), not neccessarily strictly 2 megabytes. ] ------------------------------------------------------- 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
