Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 3 Oct 2001 06:19:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 3 Oct 2001 06:19:42 -0400 Received: from s2.relay.oleane.net ([195.25.12.49]:18436 "HELO s2.relay.oleane.net") by vger.kernel.org with SMTP id ; Wed, 3 Oct 2001 06:19:33 -0400 From: Benjamin Herrenschmidt To: Alan Cox Cc: James Simmons , Linux Kernel Mailing List , Linux console project Subject: Re: Huge console switching lags Date: Wed, 3 Oct 2001 12:19:44 +0200 Message-Id: <20011003101944.29249@smtp.adsl.oleane.com> In-Reply-To: In-Reply-To: X-Mailer: CTM PowerMail 3.0.8 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> The software accel functions needed by the console layer (copyarea, >> fillrect, and drawimage) have been already written. Okay the drawimage one >> needs alot of work. I haven't benchmarked the new code versus the current > >On x86 they'll probably make no difference at all, unless the old code >is really really crap. Your bottleneck is the PCI bus. All you can do is >avoid reads. Well, there are indeed a few improvements to get with machine specific optimisations on unaccelerated framebuffer. One example is, on PPC, the use of a floating point register to do the blits 64 bits at a time. This allow the PCI host controller to generate bursts of 2 32 bits transactions (for machines with controllers unable to write combine). Of course, having such optimisations in the kernel is tricky because of the lazy FPU switching (well, at least on PPC), but the point is that improvement _is_ possible. Regards, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/