On Wed, Mar 26, 2014 at 6:12 AM, Kenneth Graunke <kenneth@xxxxxxxxxxxxx> wrote: > > The version of the command parser which landed in drm-intel-nightly (and > is now enabled by default) completely breaks the 3D driver. Running any > program - glxgears, KDE, GNOME, whatever - results in: > > intel_do_flush_locked failed: Invalid argument > > and then Mesa aborts the program. > > When Mesa initializes, it tries to submit several small batches to see > if it can write various registers. For example: > > MI_LOAD_REGISTER_IMM | (3 - 2) > OACONTROL > 0x31337000 (expected value) > <various pipe controls> > MI_STORE_REGISTER_MEM > OACONTROL > <address> > MI_LOAD_REGISTER_IMM | (3 - 2) > OACONTROL > 0 > MI_BATCH_BUFFER_END > > We then map the buffer to see what the value is. If it's our expected > value, we know we can write that register, and enable features. If not, > we disable the functionality and never write that register again. > > This works because the hardware validator implicitly converts privileged > commands (like MI_LOAD_REGISTER_IMM) to MI_NOOP, but otherwise accepts > and processes the batch. This is well-documented behavior, and we've > been relying on it since May 2013. > > In contrast, the software validator returns -EINVAL and skips executing > the batch. It rejects this particular batch since OACONTROL is not in > the kernel's register whitelist. > > I'm not sure I'm quite comfortable with the software validator > implementing different behavior than the hardware validator. Then > again, it's probably better behavior... > > Also, I'm surprised to see that the software validator is always enabled > on Haswell. The hardware validator actually works on Haswell, and the > majority of our batches don't need to run privileged commands, so it > seems like we're just burning CPU pointlessly. I thought the plan was > to have userspace add an execbuf flag to explicitly request software > scanning when it emits privileged commands, and (on Haswell) use the > hardware scanner normally. The sw validator is atm always on and returns such nasty -EINVAL so that we can catch these bugs here ;-) I'd say everything working as planned. Once we ship this we can reconsider the choice but if the perf overhead is fairly benign I wouldn't mind running this always. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
