1. 14 Jun, 2012 2 commits
    • Ben Widawsky's avatar
      drm/i915: preliminary context support · 254f965c
      Ben Widawsky authored
      
      
      Very basic code for context setup/destruction in the driver.
      
      Adds the file i915_gem_context.c This file implements HW context
      support. On gen5+ a HW context consists of an opaque GPU object which is
      referenced at times of context saves and restores.  With RC6 enabled,
      the context is also referenced as the GPU enters and exists from RC6
      (GPU has it's own internal power context, except on gen5).  Though
      something like a context does exist for the media ring, the code only
      supports contexts for the render ring.
      
      In software, there is a distinction between contexts created by the
      user, and the default HW context. The default HW context is used by GPU
      clients that do not request setup of their own hardware context. The
      default context's state is never restored to help prevent programming
      errors. This would happen if a client ran and piggy-backed off another
      clients GPU state.  The default context only exists to give the GPU some
      offset to load as the current to invoke a save of the context we
      actually care about. In fact, the code could likely be constructed,
      albeit in a more complicated fashion, to never use the default context,
      though that limits the driver's ability to swap out, and/or destroy
      other contexts.
      
      All other contexts are created as a request by the GPU client. These
      contexts store GPU state, and thus allow GPU clients to not re-emit
      state (and potentially query certain state) at any time. The kernel
      driver makes certain that the appropriate commands are inserted.
      
      There are 4 entry points into the contexts, init, fini, open, close.
      The names are self-explanatory except that init can be called during
      reset, and also during pm thaw/resume. As we expect our context to be
      preserved across these events, we do not reinitialize in this case.
      
      As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
      considered too big is arbitrary. The reason for this is even though
      context sizes are increasing with every generation, they have yet to
      eclipse even 32k. If we somehow read back way more than that, it
      probably means BIOS has done something strange, or we're running on a
      platform that wasn't designed for this.
      
      v2: rename load/unload to init/fini (daniel)
      remove ILK support for get_size() (indirectly daniel)
      add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
      added comments (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      254f965c
    • Ben Widawsky's avatar
      drm/i915: CXT_SIZE register offsets added · fe1cc68f
      Ben Widawsky authored
      
      
      The GPUs can have different default context layouts, and the sizes could
      vary based on platform or BIOS. In order to back the context object with
      a properly sized BO, we must read this register in order to find out a
      sufficient size.
      
      Thankfully (sarcarm!), the register moves and changes meanings
      throughout generations.
      
      CTX and CXT differences are intentional as that is how it is in the
      documentation (prior to GEN6 it was CXT).
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      fe1cc68f
  2. 13 Jun, 2012 3 commits
  3. 12 Jun, 2012 11 commits
  4. 06 Jun, 2012 4 commits
  5. 04 Jun, 2012 4 commits
  6. 02 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: extract object active state flushing code · 30dfebf3
      Daniel Vetter authored
      
      
      Both busy_ioctl and the new wait_ioct need to do the same dance (or at
      least should). Some slight changes:
      - busy_ioctl now unconditionally checks for olr. Before emitting a
        require flush would have prevent the olr check and hence required a
        second call to the busy ioctl to really emit the request.
      - the timeout wait now also retires request. Not really required for
        abi-reasons, but makes a notch more sense imo.
      
      I've tested this by pimping the i-g-t test some more and also checking
      the polling behviour of the wait_rendering_timeout ioctl versus what
      busy_ioctl returns.
      
      v2: Too many people complained about unplug, new color is
      flush_active.
      
      v3: Kill the comment about the unplug moniker.
      
      v4: s/un-active/inactive/
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      30dfebf3
  7. 01 Jun, 2012 5 commits
  8. 31 May, 2012 10 commits