[Mesa-dev] [PATCH] i965: Use the predicate enable bit for conditional rendering without stalling

Daniel Vetter daniel at ffwll.ch
Wed Nov 12 02:28:15 PST 2014


On Tue, Nov 11, 2014 at 11:13:28AM -0800, Kenneth Graunke wrote:
> On Tuesday, November 11, 2014 06:59:51 PM Neil Roberts wrote:
> > Kenneth Graunke <kenneth at whitecape.org> writes:
> > 
> > > drm-intel-next must have the new software checker turned on, which
> > > disallows non-whitelisted register writes (along with libva, so it
> > > can't really be enabled upstream yet).
> > 
> > For what it's worth, I get the EINVAL error even on the stock Fedora 20
> > kernel on Haswell (and presumably IvyBridge) so I can only assume the
> > software checker is already upstream, unless I'm misunderstanding
> > something.
> > 
> > $ uname -r
> > 3.16.7-200.fc20.x86_64
> > $ modinfo i915 | grep cmd_parser
> > parm: enable_cmd_parser:Enable command parsing [...]
> >       (1=enabled [default], 0=disabled) (int)
> > $ sudo cat /sys/module/i915/parameters/enable_cmd_parser 
> > 1
> > 
> > If I cat 0 to /sys/module/i915/parameters/enable_cmd_parser then I no
> > longer get the EINVAL error.
> > 
> > - Neil
> 
> Huh.  Yeah, I thought they turned it on by default in 3.16, which I don't 
> understand at all.  AFAIK the libva issue isn't fixed (or wasn't by then), so 
> it sure seems like it would've broken userspace.  Which would be a pretty 
> clear kernel policy violation...

We let libva pass. And in the latest patches from Brad if we detect libva
tricks we'll still let it pass, just not with elevated privs needed for
writing special registers. And the point of enabling the parser in 3.16
already was to have as much coverage early as possible to catch any
userspace issues we've missed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the mesa-dev mailing list