On Mon, Aug 4, 2008 at 11:40 AM, Roland Scheidegger <[EMAIL PROTECTED]> wrote: > 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.
I'd be happy to help verify the changes on older asics. I can also dig up some old cards to send you if that helps. Alex ------------------------------------------------------------------------- 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
