From mboxrd@z Thu Jan 1 00:00:00 1970 From: Abdiel Janulgue Subject: Re: [RFC] xf86-video-intel: enable hw-generated binding tables Date: Thu, 24 Apr 2014 09:08:14 +0300 Message-ID: <1582585.gcFblXjc9p@abj-desktop> References: <1398179796-5103-1-git-send-email-abdiel.janulgue@linux.intel.com> <20140423175021.GK18465@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 11FB16EBA4 for ; Wed, 23 Apr 2014 23:02:29 -0700 (PDT) In-Reply-To: <20140423175021.GK18465@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Wednesday, April 23, 2014 08:50:21 PM Ville Syrj=E4l=E4 wrote: > On Wed, Apr 23, 2014 at 06:52:09PM +0200, Daniel Vetter wrote: > > On Wed, Apr 23, 2014 at 1:21 PM, Abdiel Janulgue > > = > > wrote: > > > I've already tried disabling RS at the end of every batch so that next > > > batch in different context can continue to use older non-RS format. > > > That does not work either and still causes hangs. > > > = > > > What I've seen so far, it seems GPU does not like switching the format > > > of > > > commands from RS-format to non-RS format. It's either one way or the > > > other. If switched on, it affects subsequent contexes henceforth > > > expecting RS-format commands until the GPU gets reset. That's probably > > > the note in bspec: > > > = > > > "the binding table generator feature has a simple all or nothing mode= l". > > = > > Oh hooray, that's just awesome :( So we indeed need to stop the gpu > > and reset it if there's a non-RS render batch after any RS render > > batch. > = > I'm not sure I buy it. There's an example in the spec showing how to > disable the RS around eg. GPGPU workloads and re-enable it for 3D > workloads even within one batch. I guess it's possible that the GPGPU > pipeline mode is somehow special here, but since the RS state is > supposed to be saved to the context I'm thinking you should be able to > disable it whenever you want. > = > What's really confusing with that example is the fact that it first > re-enables the binding tables and then the RS, but then there's a note > after that saying you have to those steps in the opposite order. > = > Anyhoo, I'm wondering if the problems are simply due to disabling RS but > leaving the binding tables enabled? Yes, the work-around I tried previously is that at the end of each batch bo= th = hw-binding tables and RS are disabled in that particular order. > = > So one idea might be that when we switch from executing an RS batch to a > non-RS batch, we should disable the RS and binding tables manually. We > would then have to demand that any user batch which needs the binding > tables enabled must enable them, even if if we just executed a batch that > already used the binding tables. And when we need to disable the RS and > binding tables we could either have the kernel do that autmagically when > it notices a RS->non-RS transition, or we could also demand that all user > batches must disable the binding tables at the end. But maybe demanding > that from every batch would incur some extra overhead? In any case it > should be fairly easy to try that and see if it cures the hangs. Or are > you already doing things that way? This is actually what current RS implementation in Mesa does. It explicitly = enables RS then hw-binding tables for each batch start and then the tear-do= wn = work-around at the batch end I mentioned above; which didn't help at all. Anyway I haven't tried the work-around where we explictly only disable the = BT = and RS on the other user-space clients (xorg driver in this case) when Mesa= is = using RS instead of forcing the reset of the clients to use RS format. I'l= l = try that first and let you know if it works. If it does, it might be more = efficient to do that in the kernel? --Abdiel