On Tue, 25 Sep 2012 13:35:31 -0700, Ben Widawsky <ben at bwidawsk.net> wrote: > On Tue, 25 Sep 2012 20:41:45 +0100 > Chris Wilson <chris at chris-wilson.co.uk> wrote: > > > On Tue, 25 Sep 2012 12:04:14 -0700, Ben Widawsky <ben at bwidawsk.net> > > wrote: > > > On Tue, 25 Sep 2012 14:53:37 +0100 > > > Chris Wilson <chris at chris-wilson.co.uk> wrote: > > > > > > > "Enable hardware context support for userspace (default: > > > > disabled))"); > > > > > > You've found one platform this doesn't work on, and a bunch of > > > features rely on this, and yet we default to disabled? That seems a > > > bit harsh to me. > > > > Exactly, it's meant to be harsh. In the limited testing that hw > > contexts have been exposed to, we have a number of hangs for which > > they are implicated. Therefore they are not safe to enable yet... > > Unless you can prove otherwise. :-p > > -Chris > > > > The reason I've always resisted a module parameter is that rc6 and > contexts are tied so very closely together. We've had a number of > issues around rc6 already, I do not want contexts to be conflated with > those issues. It's interesting if rc6=0 and failures still occur. I've > yet to hear of such an issue, but I'd like to know if that's the case > here. Disabling rc6 but keeping hw contexts works but regresses performance in old school games. rc6=0 hw_contexts=0 -> works rc6=0 hw_contexts=1 -> works rc6=1 hw_contexts=0 -> works (current default up to 3.6) rc6=1 hw_contexts=1 -> hard hang with gl (new default in 3.6) -Chris -- Chris Wilson, Intel Open Source Technology Centre
