From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [PATCH] nouveau: Add irq waiting as alternative to busywait Date: Sat, 14 Jul 2012 16:09:37 +0200 Message-ID: <50017DA1.5060701@gmail.com> References: <500094B9.7040009@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id E9CB09E9C8 for ; Sat, 14 Jul 2012 07:09:40 -0700 (PDT) Received: by eaaf11 with SMTP id f11so1328136eaa.36 for ; Sat, 14 Jul 2012 07:09:40 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Maarten Maathuis Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Hey, Op 14-07-12 00:56, Maarten Maathuis schreef: > On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst > wrote: >> A way to trigger an irq will be needed for optimus support since >> cpu-waiting isn't always viable there. This could also be nice for >> power saving on since cpu would no longer have to spin, and >> performance might improve slightly on cpu-limited workloads. >> >> Some way to quantify these effects would be nice, even if the >> end result would be 'no performance regression'. An earlier >> version always emitted an interrupt, resulting in glxgears going >> from 8k fps to 7k. However this is no longer the case, as I'm >> using the kernel submission channel for generating irqs as >> needed now. >> >> On nv84 I'm using NOTIFY_INTR, but that might have been >> removed on fermi, so instead I'm using invalid command >> 0x0058 now as a way to signal completion. > Out of curiosity, isn't this like a handcoded version of software > methods? If so, why handcoded? Or are software methods not supported > on NVC0? > I don't think there is a software engine, and if you look at the code only the kernel hardware channel will be allowed to raise a wake-up interrupt. On normal channels you'll get a invalid command in dmesg. On nv84 the interrupt will be eaten unless it originated from the kernel hw channel in which case things will be woken up, since it's a valid fifo command there. Either nvc0 and later dropped the support or I wasn't able to activate it during testing. ~Maarten