I've been reading the state and dma code. I have some questions. > The intention is to instead use > a pool of private buffers not mapped to userspace (rather than continually > unmapping and mapping client buffers). The part that is missing (and > preventing us from merging with the trunk) is a way to allocate and use a > set of private unmapped buffers in addition to the client buffers in the > DRM.
So would there be one set of unmapped buffers that are used for everything, and then a set of client, mapped buffers that are just used for state (only in mach64_state.c:mach64_dma_dispatch_vertex()?)? Or is it the other way around, some unmapped buffers just for copying state data to before it is emitted. The second way seems wrong to me, but that was what I thought Leif was describing in his earlier mail. I was going to start modifying the free list routines to allow for two lists per dev_priv structure, one mapped/one unmapped. I would add another freelist structure to drm_mach64_private_t. Would this type of change mean I could remove the placeholders list? Is this the propper way to go? -James ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
