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. cu, Nicolai ------------------------------------------------------------------------- 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
