Dave Airlie wrote: > >> 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. > >
Yes, let's see how that ends up. Anyway, the ttm vm code will need ttm_bo objects, but not vice versa, so the driver could actually plug in any vm handler for these objects. This also might come in handy for replacing fbdev fops, where drm may actually decide which buffer object is currently backing the user-space fbdev "display memory", and switch "on-the-fly". > > 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. > > OK. /Thomas > 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
