From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 00/18] i915 HW Context Support Date: Thu, 29 Mar 2012 21:51:33 +0200 Message-ID: <20120329195133.GK27737@phenom.ffwll.local> References: <1332103198-25852-1-git-send-email-ben@bwidawsk.net> <20120319101432.GA6867@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by gabe.freedesktop.org (Postfix) with ESMTP id 7A78D9F648 for ; Thu, 29 Mar 2012 12:50:50 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so121382wgb.0 for ; Thu, 29 Mar 2012 12:50:49 -0700 (PDT) In-Reply-To: <20120319101432.GA6867@phenom.ffwll.local> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Mon, Mar 19, 2012 at 11:14:32AM +0100, Daniel Vetter wrote: > On Sun, Mar 18, 2012 at 01:39:40PM -0700, Ben Widawsky wrote: > > The patches have changed quite a bit since the RFC, and therefore I > > didn't feel comfortable trying to do v2 information. I didn't feel > > comfortable taking the few r-bs that I had from the RFC except for the > > one patch that I applied wholesale. > > > > Summary: > > - Completely redid the patch splitting. > > I've only done a quick and cursory reading, but I like the new splitting > _much_ more. The storyline behind these patches is now much clearer. I'll > try to do a more in-depth review later this week. Ok, I've gone through it and noticed a few things - mostly stuff that are imo more complicated than necessary and that could be cut out. Safe for the tlb flush wa I haven't cross-checked anything with Bspec, but I don't expect any surprises there. I also haven't checked how good the test coverage is (safe for suggesting that one test for execbuf failure handling). But again, that's something which can be easily fixed. The last thing I'm wondering is: How ready is mesa for this? I'd like to merge this only when the mesa patches are ready to put it to good use. Otherwise we run the decent risk of shipping broken code, which could end up in a decent pain for userspace (worst case we have to add a new flag to claim 'fixed context support'). Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48