1. 18 Mar, 2010 1 commit
    • Kristian Høgsberg's avatar
      intel: Call _mesa_make_current() after getting initial buffers · 6de8e563
      Kristian Høgsberg authored
      The default viewport is the window rectangle, which is set up by
      _mesa_make_current().  To be able to do that we need to get the
      window dimension (and buffers) first, so we have to call
      intel_prepare_render() before we can call into _mesa_make_current().
      Fixes #26676 and #26678.
  2. 05 Mar, 2010 1 commit
    • Eric Anholt's avatar
      intel: Remove non-kernel-exec-fencing support. · bb35000b
      Eric Anholt authored
      Shaves 60k off the driver from removing the broken spans code.  This
      means we now require 2.6.29, which seems fair given that it's a year
      old and we've removed support for non-KMS already in the last release
      of 2D.
  3. 02 Mar, 2010 1 commit
  4. 25 Feb, 2010 2 commits
  5. 24 Feb, 2010 1 commit
    • Kristian Høgsberg's avatar
      intel: Call intel_prepare_render() in intelMakeCurrent() · db9c151d
      Kristian Høgsberg authored
      This restores old behaviour, where we end up doing a DRI2GetBuffers()
      call from intelMakeCurrent().  The idea was that we could do this
      lazily, just before we start rendering.  However, if we don't do the
      DRI2GetBuffers() round-trip we don't get the drawable size and higher
      level mesa ends up short-cutting a number of GL calls, such as glClear().
  6. 22 Feb, 2010 1 commit
  7. 19 Feb, 2010 2 commits
  8. 18 Feb, 2010 1 commit
    • Kristian Høgsberg's avatar
      intel: Implement the DRI2 invalidate function properly · d4496278
      Kristian Høgsberg authored
      This uses a stamp mechanisms to mark the DRI drawable as invalid.
      Instead of immediately updating the buffers we just bump the drawable
      stamp and call out to DRI2GetBuffers "later".
      "Later" used to be at LOCK_HARDWARE time, and this patch brings back
      callouts at the points where we used to call LOCK_HARDWARE.  A new function,
      intel_prepare_render(), is called where we used to call LOCK_HARDWARE,
      and if the buffers are invalid, we call out to DRI2GetBuffers there.
      This lets us invalidate buffers only when notified instead of on
      every glViewport() call.  If the loader calls the DRI invalidate
      entrypoint, we disable viewport triggered buffer invalidation.
      Additionally, we can clean up the old viewport mechanism a bit,
      since we can just invalidate the buffers and not worry about
      reentrancy and whatnot.
  9. 16 Feb, 2010 1 commit
    • Francisco Jerez's avatar
      dri2: Event driven buffer validation. · 61d26bc8
      Francisco Jerez authored
      When a buffer invalidation event is received from the X server, the
      "invalidate" hook of the DRI2 flush extension is executed: A generic
      implementation (dri2InvalidateDrawable) is provided that just bumps
      the "pStamp" sequence number in __DRIdrawableRec.
      For old servers not supporting buffer invalidation events, the
      invalidate hook will be called before flushing the fake front/back
      buffer (that's typically once per frame -- not a lot worse than the
      situation we were in before).
      No effort has been made on preserving backwards compatibility with
      version 2 of the flush extension, but I think it's acceptable because
      AFAIK no released stack is making use of it.
      Signed-off-by: Kristian H. Kristensen's avatarKristian Høgsberg <krh@bitplanet.net>
  10. 12 Feb, 2010 2 commits
  11. 11 Feb, 2010 2 commits
  12. 31 Jan, 2010 1 commit
  13. 26 Jan, 2010 2 commits
  14. 23 Jan, 2010 1 commit
  15. 19 Jan, 2010 1 commit
    • Eric Anholt's avatar
      intel: Use the new DRI2 flush invalidate entrypoint to signal frame done. · 7d4e674b
      Eric Anholt authored
      Previously for frame throttling we would wait on the first batch after
      a swap before emitting another swap, because we had no hook after a
      swap was emitted.  This meant that if an app managed to squeeze
      everything it for a frame had into one batch, it would lock-step with
      the GPU.  With the swapbuffers changes, we now have the entrypoint we
      This takes the WoW intro screen from 25% GPU idle and visibly jerky to
      4-5% GPU idle and rather smooth.  Other apps such as OpenArena have
      run into this problem as well.
  16. 08 Jan, 2010 1 commit
  17. 04 Jan, 2010 7 commits
  18. 29 Dec, 2009 1 commit
  19. 22 Dec, 2009 5 commits
  20. 19 Nov, 2009 2 commits
  21. 12 Nov, 2009 1 commit
  22. 06 Nov, 2009 1 commit
  23. 29 Oct, 2009 1 commit
  24. 23 Oct, 2009 1 commit