[Intel-gfx] [PATCH] drm/i915: Update write_domains on active list after flush.
daniel at ffwll.ch
Mon Feb 1 04:26:14 PST 2010
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. :-)
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?
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx