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