On Wed, Sep 10, 2008 at 8:03 PM, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Dave Airlie wrote: >> >> Hi Thomas, >> >> I've made some changes you might be interested in on the >> modesetting-gem branch of the main repo. >> >> 1. removed all the TTM interfaces and ioctls from the kernel API. >> 2. removed drm_bo_lock.c (we need to discuss what we want that for) >> 3. built a radeon GEM interface on top of the TTM internals. >> > > Dave, > I plan to pick up this code and do the following: > > 1) The drm_bo.c, drm_bo_move.c, and drm_fence.c files will to into > ttm/ttm_bo, ttm/ttm_bo_util, and ttm/ttm_fence. Functions and types will be > prefixed ttm_ instead of > drm and all (if not already done) user-space interaction will be stripped, > as well as the dev->struct_mutex > dependance, but in essence the interfaces you use in the Radeon code will be > kept with minimal changes.
Makes sense, I'm happy to change the internals interfaces at any time. > 2) Radeon logically derives from drm_gem_object and ttm_bo to obtain the > buffer objects, which is fine. > I plan to add ttm_base object code so that it is possible to derive from > ttm_base_object and ttm_bo to obtain buffer objects > visible to user space and ttm_base_object and ttm_fence_object to obtain > buffer- and fence objects visible to > user space. However, this construct is entirely optional for a driver writer > and only for those drivers that don't use GEM, > or want to make fence objects visible to user-space for swapbuffer > throttling, sub-allocation and command stream > error reporting (mainly video acceleration). > It's intended to suit the user-space interface posted for review earlier. > The ttm_base_object code will also live separately in the ttm subdirectory. > The per-file and per-device management code for the ttm_base_objects will be > called from the device driver load / unload / fops hooks. > > 3) The ttm_bo vm code will still be closely tied to the ttm_bo object, but > needs to be moved out from the drm core. > The plan is to have separate ttm_mmap() ttm_read() and ttm_write() > functionality for the driver to use in the .fops hooks. > If any of these functions detect (based on the address space offset) that > we're dealing with a legacy drm map, the corresponding drm core function > will be called instead. Yes that makes sense, it may interact with how GEMs GTT mappings end up working, not sure that interface is fully specified yet. > 4) Swapout. (long term) > I think this is most easily handled by demand-allocation of shmem objects > into which we either copy or > DMA the data. In the Radeon case, it should be easy to use the GEM shmem > object. Yes I'm currently just allocating the shmem object with no pages backing it. I plan on just kicking the pages into cached mappings and shoving them into the backing object address mapping. Then shmem will take care of swapping the data hopefully. > > 5) Write-combined / unmapped page pool (long term). > Did you ever get to implement this? I think it's still a very desirable > thing, but it looks like > the effect of buffer creation / destruction latency for at least > fire-and-forget buffers > (some pbos, temporary drawpixels / glbitmap, exaUploadToScrach) can be > worked around > by using VRAM or a small pre-bound AGP area. I've started this using a simple idr allocator, I got a bit sidetracked into doing filesystem based on shmem, before I realise it was probably pointless. http://cgit.freedesktop.org/~airlied/drm/tree/linux-core/drm_uncached.c?id=a4554d1f4c6d7adaad755789fe5106819a46f59a is the last bits of the uncached allocator I got to. I realised one problem with buffer reuse when VRAM is involved, we have some 2D operations, that always work on the buffer in local RAM, migrated to GTT or VRAM and blit from there. Reusing those buffers is a lot more overhead than throwing it away. It made me realise doing page reuse in the kernel may be a better plan. Dave. ------------------------------------------------------------------------- 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=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
