From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC] Explicit synchronization for Nouveau Date: Tue, 30 Sep 2014 10:21:51 +0200 Message-ID: <20140930082151.GF24667@phenom.ffwll.local> References: <1411725612-10455-1-git-send-email-lpeltonen@nvidia.com> <20140929074302.GB4109@phenom.ffwll.local> <20140929154217.GA2851@gmail.com> <542994EC.4060009@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by gabe.freedesktop.org (Postfix) with ESMTP id 405026E165 for ; Tue, 30 Sep 2014 01:21:56 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so3333190wes.34 for ; Tue, 30 Sep 2014 01:21:55 -0700 (PDT) Content-Disposition: inline In-Reply-To: <542994EC.4060009@nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: James Jones Cc: Stephen Warren , "nouveau@lists.freedesktop.org" , Colin Cross , "dri-devel@lists.freedesktop.org" , Ben Skeggs , Daniel Vetter , Dave Airlie , Thierry Reding , Ken Adams List-Id: dri-devel@lists.freedesktop.org On Mon, Sep 29, 2014 at 10:20:44AM -0700, James Jones wrote: > Additionally, I think the goal is to move to a model where some higher-level > object such as a working set, rather than individual buffers, are assigned > counters or sync primitives on a per-submission basis. Versioning off tags > for individual buffers then moves to working set modification time. This is > more feasible if the only thing that needs precise fencing of individual > surfaces is lifetime management. Yeah, there's always ways to make the fence assignment and tracking a bit more efficient, we're playing around with working-set tricks for i915 ourselves. But fundamentally you still have fences for each buffer object (just can't directly access them). And for buffers exported with dma_buf you still need the direct link I think, at least when you care about implicit syncing somewhat. > The trend seems to be towards establishing a relatively large working set up > front and then submitting many command buffers against it, perhaps with > incremental modifications to the working set along the way. This may be > what's referred to as the Android model above, but I view it as the > "non-glitchy graphic" model going forward. Nah, that's something different. Afaik Android drivers don't really bother a lot with swap and page migration and having a working shrinker for gpu objects. At least our android guys need to disable the lowmemory killer since that thing just goes bananas if we driver i915 memory usuage against the wall and into swap. I'm not really sure what you mean by "non-glitchy graphics", for me this can mean anything from avoiding stalls to proper syncing with vblanks to anything else really ... So might be good to elaborate here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch