Austin Yuan wrote: > Hi, Thomas > > On Mon, Sep 8, 2008 at 7:07 PM, Thomas Hellström > <[EMAIL PROTECTED]> wrote: > >> Hi! >> >> For those drivers that for whatever reason will not be using GEM but >> interface directly to the TTM code, I've made a suggestion for >> a new user-space interface. The header files are attached to the mail. >> >> The idea here is that a driver wanting to use this interface includes >> one or more of these header files in the <driver>_drm.h file, and >> implements the IOCTLS as driver-specific code. >> The ioctl numbers are given as offsets, and the user-space code needs to >> query the driver for the base numbers. >> >> User-space fencing is completely decoupled from buffer management. >> >> mapping write and read will be done using the standard fs calls, >> > So previous TTM buffer usage pattern > (CreateBuffer,MapBuffer,Write/ReadBuffer,UnmapBuffer,CommitBufferToHW > by IOCTL, ValidateBuffer,Relocation,FenceBuffer) hasn't big change > except that now Map/RW/Unamp is replaced by pread/pwrite? > No. In fact there is no big change in usage pattern. Map / RW / Unmap is there, except it works without syncing. So to mimic the old behaviour you'd do
map() sync_for_cpu() RW release_from_cpu() unmap() read() / write() will work in the same way, but contrary to GEM, buffer start is not at offset 0, but at the mmap() offset. > And previous, MapBuffer is blocked when the buffer isn't unfenced by > HW, now does pread/pwrite have similar mechanism? > Yes, optionally. See above. >> each buffer object will, as before, occupy a part of the linear drm fd >> address space which (even on 32-bit systems) is 48 bits wide. >> The create- and reference ioctls return the address space offsets for the >> buffers. >> > Now for a TTM BO, will it derive from a SHMEM object, or it depends on > specific driver? > > No, it will not. Note that this user interface suggestion is not set in stone for each driver that uses the TTM functionality, but the user interface TG will most probably use for drivers not deriving from GEM objects. The Radeon driver takes another approach and derives BOs from GEM objects and TTM BOs. In that case, the above user interface does not apply. > >From ttm_placement_user.h, it seems now TTM BO doesn't support user > buffers. For the case that I want to pass a special memory token to > kernel to indicate TTM to create a BO from the pages specified by the > user space memory token, how can I achieve it, especially if a TTM BO > derive from a SHMEM object? Can I create a SHMEM object with any > pages backing it ? > It's possible to create a shmem object without any pages backing it, if needed. For user-buffers one should probably construct a separate driver-specific IOCTL. Since this is an RFC, and I agree that user-buffers are sometimes very handy I'll include a user-buffer create IOCTL and send out a new version. > Some examples of above use case, map pages which store frames from a > camera into graphics memory space and then display or encode it > directly avoiding a memory copy, video or display engine operates on > pages locked by a security engine and CPU access is forbidden for > digital rights management purpose. Those cases needs user space stuff > pass some special private date to kernel memory manager for BO > creation. > > OK. > Thanks > Austin > >> Execbuf and similar ioctls will be completely driver specific. >> >> I anticipate no code for this to live in drm core. The vm code will use >> the driver vm hooks and detect legacy drm maps and forward those calls >> to the drm vm subsystem. >> >> /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
