On 03.08.2008 00:40, Nicolai Hähnle wrote: > Hi there, > > seeing as lacking a memory manager is a pretty frustrating state of mind, I > thought I'd explore this area a bit. > > My goals are: > - bring the r300_dri driver into a state that is more compatible with a > proper > in-kernel memory manager, > - do so with as little breakage as possible, and > - do so without changes to DRM or DDX (binary compatibility and all that) > Basically, I want to have a development tree that is in almost-perfect > condition almost all the time while moving towards memory management. > > My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master branch) > > Some comments about this tree: > 1. I decided not to use an approach based on dri_bufmgr_fake yet. Instead, I > based the bufmgr on the existing r300_mem which uses the RADEON_ALLOC/etc. > ioctls to allocate buffers for DMA. > > 2. Textures are still handled in the old way - they will require > dri_bufmgr_fake-like handling, probably more like airlied's approach. > > 3. The tree contains a lot of patches to unify the way command buffer emits > are done. Basically, I introduced macros BEGIN_BATCH/OUT_BATCH/etc. similar > to what we have in the DRM and the DDX - hopefully, this will reduce > confusion for new people. > There's a new macro called COMMIT_BATCH. The idea behind this macro is that > BEGIN_BATCH can flush the command buffer at times where we really don't want > the command buffer to be flushed (flushing between certain kinds of packet3 > can cause lockups, etc.). The COMMIT_BATCH indicates a point in time where > flushing the command buffer is unproblematic, and it should probably be used > rarely. Together with r300EnsureCmdBufSpace there's a chance that it'll yield > good results. > > 4. dri_bufmgr-API #1: Allocating space for the command buffer via > DRM_RADEON_ALLOC would be kind of silly, but the command buffer has to be a > dri_bo. So I "overloaded" the flags parameter of the dri_bo_alloc call to > tell the bufmgr what kind of memory the caller wants. > > 5. dri_bufmgr-API #2: Radeon hardware has some very weird relocation > requirements. So far, the only one I've dealt with is that the blitter > command contains a dword which combines a buffer offset with a buffer pitch. > I've "overloaded" the emit_reloc flags parameter to tell the bufmgr about the > relocation type. > > I would like to go ahead with this work and merge it back to Mesa master > pretty soon (that's the whole point of this little exercise), after making it > more complete and running it through thorough testing. Please tell me if I'm > running off in a completely stupid direction.
Not looked closely at it, but this sounds pretty reasonable to me (ok - the 3 texture copies do not). Any plans on converting r200/radeon too? Roland ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
