P.S.: Sorry to the list admins for repeatedly sending this from the wrong account...
Am Sonntag 03 August 2008 00:40:30 schrieb Nicolai Hähnle: > 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) I've pushed some more work. The tree builds together with the standard mesa/drm master. Basic things work (i.e. an arbitrary sample of piglit tests, openarena, nexuiz, glxgears). In the current version, textures are now managed via the bufmgr. It's not exactly efficient yet, as there will be three copies of texture data in memory (one for Mesa, one for bufmgr backing store, and one in vram). This can be dealt with by taking even more ideas from the Intel driver. My bufmgr allocates blocks in vram by wrapping the old dri/common/texmem.c code. This means that it internally carries around driTextureObjects, even though the blocks need not contain texture data. The advantage is that we should get cooperative vram sharing between processes without additional work. I have identified three points where my tree is still lacking compared to other bufmgr trees: 1) I haven't implemented static allocations yet, i.e. the framebuffer is not represented as a buffer object. 2) I'm not using fences at all. In-flight buffers are handled correctly, though, and swap buffers and waiting (e.g. r300Finish) simply uses the old synchronization code. 3) I'm not using check_aperture_space. Mostly this is because check_aperture_space seems a little voodoo and heuristic to me and I didn't quite know what to do with it. Instead my tree relies on the same heuristics that the driver has always relied on in the past, and that works so far. And now, from my completely subjective point of view, the advantages over other trees: 1) All memory objects (including textures) are handled by the bufmgr. 2) The driver's behaviour as seen by external parties has only changed marginally: RADEON_ALLOC/_FREE and the sarea based texture heap protocol are still used so that process interaction should be better. 3) Most importantly: It works. 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
