From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH 0/8] drm/i915/context Date: Wed, 2 Feb 2011 15:55:31 -0800 Message-ID: <20110202235531.GA5345@snipes.kumite> References: <1296687620-27019-1-git-send-email-bwidawsk@gmail.com> <0d30dc$kupvbd@orsmga001.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-yw0-f49.google.com (mail-yw0-f49.google.com [209.85.213.49]) by gabe.freedesktop.org (Postfix) with ESMTP id A872A9E7BE for ; Wed, 2 Feb 2011 15:55:21 -0800 (PST) Received: by ywf7 with SMTP id 7so256034ywf.36 for ; Wed, 02 Feb 2011 15:55:21 -0800 (PST) Content-Disposition: inline In-Reply-To: <0d30dc$kupvbd@orsmga001.jf.intel.com> 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: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Feb 02, 2011 at 11:29:37PM +0000, Chris Wilson wrote: > I don't think we should be pinning contexts for their entire lifetime. > The page should only be pinned whilst it is being referenced by the > hardware, and it looks like you already parts of the infrastructure to > be able to track this. You will also need to track seqno and retire > contexts... > I have given thought to not pinning the contexts multiple times, and believe it is ultimately what we will end up doing. However, the current implementation is definitely the easier, and more stable way to go about it. So I'd definitely prefer to keep this as is until the other parts of the stack are functional. We need to consider how many clients we will actually have at one time. I have no idea. If we're talking a common case of 2 or 3 contexts, the overhead may not be worth it. Retiring of contexts is very simple the way it is now too because it only happens voluntarily. > I'm not convinced by the locking strategy, there seems to be quite a few > holes left, and is something else that is much easier to make it correct > from the beginning and incrementally adjust. Yes, I still need to review this, and I totally agree that it must be right the first time. Is there something in particular that bothers you about it? > > And then there are lots of little changes to try and make the code > tidier... But those are probably best left for another day. > -Chris Thanks for the feedback. Ben