On Thu, Mar 27, 2014 at 04:42:21PM -0700, Volkin, Bradley D wrote: > On Thu, Mar 27, 2014 at 01:16:26PM -0700, Daniel Vetter wrote: > > On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D > > <[email protected]> wrote: > > > On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote: > > >> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether > > >> it's > > >> an issue with the test or the checker: > > >> > > >> https://bugs.freedesktop.org/show_bug.cgi?id=76670 > > > > > > For this one, the parser rejects an MI_STORE_REGISTER_MEM with the GGTT > > > bit > > > set. We don't currently allow that, even from master. It sounds like there > > > might be released versions of the ddx that do this as well. If that's the > > > case, or if there are other situations where tests, etc rely on being able > > > to do whatever they want when setting the I915_DISPATCH_SECURE flag, then > > > I > > > think we might as well stop parsing secure batches and let them go through > > > as before. > > > > Well for the testcase I think we can just add the missing flag. If > > Which flag are you referring to here? Or are you just generally trying to say > "modify the test to not break the rules"? > > > there's indeed shipping userspace out there which is getting these > > flags wrong then I think we need to silently upgrade them when copying > > the cmds over to the 2nd batch. But I guess until that need is really > > established we can hope we don't need this. > > Chris, can you clarify whether shipping ddx sets GGTT bits this way?
There have been no point releases with SRM (as far as I can remember) as no bug reporter said that they made any difference to their hangs. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
