[Intel-gfx] [PATCH] drm/i915: report all active objects as busy v2

[Daniel Vetter]

On Sun, May 02, 2010 at 11:13:18AM -0700, Eric Anholt wrote:
> I've thought about writing this patch several times.  Here's my concern.
> Say I drew to an FBO (render cache dirty) temporarily then freed it.  It
> goes into the bo reuse list in userland, and is on the flushing list in
> kernel.  Now I start doing a bunch of texturing -- allocating and
> deleting objects, only flushing the texture cache.  When I go to
> allocate, I see that that old FBO object is busy, and allocate new
> instead of using cache.  When I free, I put my thing at the end of the
> list.  Memory usage goes up and up and up.

This should not happen because the first busy_ioctl will flush all pending
write domains. If the gpu eventually comes around to executing this flush,
a subsequent ioctl call will report this fbo object as non-busy, hence it
can be reused.

> Also, note that that ioctl says it's trying to implement OpenGL
> semantics.  Please don't change its behavior and break those semantics.

I've thought the semantics this ioctl should implement are as follows:
a) An object should be reported busy if a subsequent map of the same
object without any other operations in between will not have to wait for
the gpu. The old implementation fails this for not yet flushed objects.
b) An object should become non-busy eventually. In practical terms this
means the following loop terminates in finite time:

while (object_is_busy)
	;

[Minus gpu hangs, of course]. Both implementations follow this.

> It seems like the problem here is that userland doesn't know the
> active/flushing distinction, and if it did it could manage its lists
> almost in parallel to the kernel's list and reuse the right BOs at the
> right times.  So maybe make a new busy ioctl that returns both active
> and flushing booleans?  Then libdrm can be smart and OpenGL can be
> happy.

This would leak gem implementation details out to userspace. IMHO this is
a path paved with good intentions leading directly to hell. If this really
is a problem perhaps a ioctl to tell the kernel that "userspace needs the
contents of this buffer asap, do whatever is needed" is the cleaner
abstraction.

> (Actually, OpenGL would be happier if the thing it was asking for
> results on got off the flushing list sooner please.  It's trying to get
> the results of PIPE_CONTROL writes, and right now we're faking tracking
> that using GEM_DOMAIN_INSTRUCTION as the write domain).

I'll look into that use case.

On a related note: While forward porting and benchmarking my exact fence
lru for execbuf2 stuff from the pipelined fencing series I've noticed that
at least uxa accel on my i855 is very sensitive to how we emit gpu
flushes. Results easily vary by up to a factor of two on certain cairo
traces.

So please hold off on this one till it's clear what's going on and what
exactly userspace needs/wants.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48