[Intel-gfx] [PATCH] drm/i915: Update write_domains on active list after flush.

[Daniel Vetter]

On Sun, Jan 31, 2010 at 04:40:17PM +0000, Chris Wilson wrote:
> Daniel, can you respin your earlier patches as I think there were a couple
> of good bug fixes that were lost in the noise. And then we can take a
> fresh look at the others, and see if I said anything very silly.  :-)
> -ickle

Will do somewhen later today.

btw, I've thought a bit about why you want to do such crazy tricks with
flushes in the middle of batchbuffers. I've come up with the follwing.

1) Per execbuf-ioctl overhead on the cpu. I haven't seen anything obvious
there. But even when profiling points this way, IMHO it's better to fix it
than to paper over it by issuing fewer ioctls.

2) Per execbuf gpu<->cpu synchronization (e.g. too many interrupts). Code
as-is is quite suboptimal, for when we need some flushes, we already emit
more than one interrupt per execbuf. There's also an XXX already there
no one yet bothered to fix. I have some ideas there to mitigate this (as
prep work for something else).

3) Per execbuf overhead for the gpu due to the need to re-emit all the
necessary state (shaders, tex-units, ...). My idea to fix this:

 - exebuf-ioctls returns a cookie for every batchbuffer.
 - userspaces emits commands as if it owns the hw (like dri1).
 - when doing the next execbuffer ioctl, it also sets the cookie from the
   last execbuffer ioctl.
 - kernel checks wheter any other batchbuffer was executed in between (by
   checking the cookie from userspace). If the cookies don't match, it
   errors out with a new error-code.
 - when userspace sees this special error-code, it creates a new
   batchbuffer with a complete re-emit of the full gpu state.

Of course, this needs some fancy new userspace code to take advantage of.
But this way a user can be more fair towards other users (by issuing
smaller execbufs) without a performance loss in the normal case of one
process hogging the gpu (e.g. giant vbo's with compute-intense shaders
could be split-up).

Comments? Other problems I've missed?

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