[Intel-gfx] [PATCH] drm/i915: Perform a flush on throttle.

Chris Wilson chris at chris-wilson.co.uk
Fri Feb 13 22:10:19 CET 2009

On Fri, 2009-02-13 at 12:18 -0800, Eric Anholt wrote:
> I don't really like this one.  The point of this ioctl is just to keep
> an individual application from getting too far ahead of itself (and
> starving interactivity of others in the process) -- I don't really want
> it to be a cache management ioctl.  In particular, having the X Server
> doing this on blockhandler means that whenever you ask it for some
> information, your GPU read caches are blown away -- ouch!

Ok, this is where I fail to see the difference between the X server
doing the MI_FLUSH | INVALIDATE_BITS, and the kernel performing it on
the clients behalf. Hmm... I think I am just confused about what you
intended the semantics of this to be. (For example just how is the limit
to 20ms lag obtained?)

So far in my cursory experience, almost all the callers of throttle will
do a manual flush before hand -- in my case, I thought it is necessary
as there are comments implying that you need to flush and invalidate to
ensure that scan out buffers are updated.

> An application that found the allocation of batches to MI_FLUSH to be
> too expensive could simply reuse an existing BO containing just the

True, but that loses out on the advantage of the kernel being able to
retire bo's from its flushing lists.

More information about the Intel-gfx mailing list