On 04.08.2008 15:05, Nicolai Hähnle wrote: > Am Montag 04 August 2008 14:51:37 schrieb Roland Scheidegger: >> 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? > > Yes, the 3 texture copies suck. My plan is to override gl_texture_image like > in the intel driver. That way we can go back to 2 texture copies (and > eventually a single texture copy with proper memory management).
> > As for r200/radeon: I don't have any such hardware, and I don't want to make > massive changes in code that I cannot test. Ok, fair enough. It's just that this is code which probably should be shared between all 3 drivers. There are basically no differences wrt memory management or command submission for those chips, and it would probably simplify maintenance if they could share this code. 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
