On Wed, Sep 10, 2008 at 8:03 PM, Thomas Hellström
> 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.
> 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
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.
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
reuse in the kernel may be a better plan.