From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 15/16] drm/i915: fixup in-line clflushing on bit17 swizzled bos Date: Mon, 26 Mar 2012 10:18:39 +0100 Message-ID: <1332753528_97351@CP5-2952> References: <1332697663-31256-1-git-send-email-daniel.vetter@ffwll.ch> <1332697663-31256-15-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id 250AA9EEF9 for ; Mon, 26 Mar 2012 02:18:51 -0700 (PDT) In-Reply-To: <1332697663-31256-15-git-send-email-daniel.vetter@ffwll.ch> 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: Intel Graphics Development Cc: Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Sun, 25 Mar 2012 19:47:42 +0200, Daniel Vetter wrote: > The issue is that with inline clflushing the clflushing isn't properly > swizzled. Fix this by > - always clflushing entire 128 byte chunks and > - unconditionally flush before writes when swizzling a given page. > We could be clever and check whether we pwrite a partial 128 byte > chunk instead of a partial cacheline, but I've figured that's not > worth it. There's some black magic here that I haven't fully grasped. We only ever swizzle the gpu address (by whole cachelines), so why do we need to invalidate a pair of cachelines for a single cacheline write? Also we have a lot of assumptions that the cacheline is 64 bytes. Have we tested on gen2 where the GPU cacheline is 32 bytes? -Chris -- Chris Wilson, Intel Open Source Technology Centre