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. 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. 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. 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. Does this sound acceptable? /Thomas ------------------------------------------------------------------------- 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
