« TuxMessenger | Home | Mutopia »

August 4, 2009

KMS X.Org Driver - Almost

The lack of posting on this subject recently has simply been because I've, erm, been coding too hard.  Here's a picture of the latest situation: An X.Org driver running on a Neo FreeRunner, plus or minus a few "issues" which need ironing out:

kms-fr-almost.jpgOne of the more interesting parts of the recent hackathon has been the way GEM objects, held in Glamo's VRAM, are mapped into the address space of a process.  In this way, a process can access something - such as an offscreen pixmap, the overall X framebuffer or later something such as a vertex list or texture object - in an unaccelerated fashion.  Unaccelerated accesses have to happen at some point (we have to get data into Glamo at some point before more exciting accelerated things can be done with that data), so this isn't a bad thing and is quite important in the grand scheme of things.  The way it works has a few steps:

  1. The process calls our ioctl, DRM_IOCTL_GLAMO_GEM_MMAP, passing the handle of the GEM object it's interested in mapping.
  2. The kernel generates an offset, and records it in a list next to the GEM handle.  The DRM device, /dev/dri/card0, behaves as if it were a huge file, sections of which correspond to GEM objects that have been mapped.  The offset gets returned to the process.
  3. The process calls mmap() with its file descriptor (corresponding to /dev/dri/card0), the offset and size of the object.
  4. The core bits of kernel generate a new virtual memory area (VMA) for the newly mmap'd area, and pass control to DRM.
  5. DRM looks up the offset in its list, and - if found - sets up some flags on the VMA.  Notice that nothing has actually used the true physical memory address of the VRAM yet.
  6. The kernel returns the start address of the new VMA to the process, which tries to access its contents.
  7. The access to the memory generates a page fault, which gets passed back through the kernel and eventually ends up in our DRM driver.  Finally, we set up the page tables so that the virtual address given to the process actually corresponds to the VRAM inside Glamo.
An interesting point is that the page tables are only actually set up for the pages of VRAM which are accessed, i.e. there's no penalty for accessing a small region of a very large GEM object.

Leave a comment