From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Date: Wed, 22 Feb 2012 16:36:32 +0000 Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Message-Id: List-Id: References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1775349.d0yvHiVdjB@avalon> <20120217095554.GA5511@phenom.ffwll.local> <2168398.Pv8ir5xFGf@avalon> <20120222162424.GE4872@phenom.ffwll.local> In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Daniel Vetter , James Simmons Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Marcus Lorentzon , Pawel Osciak , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , linux-media@vger.kernel.org, Marek Szyprowski On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote: > > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3 > > possible accels; copyarea, imageblit, and fillrect. The first two could be > > hooked from the TTM layer. Its something I plan to experiment to see if > > its worth it. > > Let's bite into this ;-) I know that fbcon scrolling totally sucks on big > screens, but I also think it's a total waste of time to fix this. Imo > fbcon has 2 use-cases: > - display an OOSP. > - allow me to run fsck (or any other desaster-recovery stuff). 3. Show panics. Ensuring that nothing prevents the switch to fbcon and displaying the panic message is the reason why we haven't felt inclined to accelerate fbcon - it just gets messy for no real gain. For example: https://bugs.freedesktop.org/attachment.cgi?idH933 which doesn't handle flushing of pending updates via the GPU when writing with the CPU during interrupts (i.e. a panic). -Chris -- Chris Wilson, Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Date: Wed, 22 Feb 2012 16:36:32 +0000 Message-ID: References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1775349.d0yvHiVdjB@avalon> <20120217095554.GA5511@phenom.ffwll.local> <2168398.Pv8ir5xFGf@avalon> <20120222162424.GE4872@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id DBC939E81B for ; Wed, 22 Feb 2012 08:36:41 -0800 (PST) In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local> 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: Daniel Vetter , James Simmons Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Marcus Lorentzon , Pawel Osciak , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , linux-media@vger.kernel.org, Marek Szyprowski List-Id: dri-devel@lists.freedesktop.org On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote: > > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3 > > possible accels; copyarea, imageblit, and fillrect. The first two could be > > hooked from the TTM layer. Its something I plan to experiment to see if > > its worth it. > > Let's bite into this ;-) I know that fbcon scrolling totally sucks on big > screens, but I also think it's a total waste of time to fix this. Imo > fbcon has 2 use-cases: > - display an OOSP. > - allow me to run fsck (or any other desaster-recovery stuff). 3. Show panics. Ensuring that nothing prevents the switch to fbcon and displaying the panic message is the reason why we haven't felt inclined to accelerate fbcon - it just gets messy for no real gain. For example: https://bugs.freedesktop.org/attachment.cgi?id=48933 which doesn't handle flushing of pending updates via the GPU when writing with the CPU during interrupts (i.e. a panic). -Chris -- Chris Wilson, Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga01.intel.com ([192.55.52.88]:25595 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753772Ab2BVQgm (ORCPT ); Wed, 22 Feb 2012 11:36:42 -0500 Message-Id: From: Chris Wilson Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes To: Daniel Vetter , James Simmons Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Marcus Lorentzon , Pawel Osciak , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Rob Clark , Marek Szyprowski , linux-media@vger.kernel.org In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local> References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1775349.d0yvHiVdjB@avalon> <20120217095554.GA5511@phenom.ffwll.local> <2168398.Pv8ir5xFGf@avalon> <20120222162424.GE4872@phenom.ffwll.local> Date: Wed, 22 Feb 2012 16:36:32 +0000 Sender: linux-media-owner@vger.kernel.org List-ID: On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote: > > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3 > > possible accels; copyarea, imageblit, and fillrect. The first two could be > > hooked from the TTM layer. Its something I plan to experiment to see if > > its worth it. > > Let's bite into this ;-) I know that fbcon scrolling totally sucks on big > screens, but I also think it's a total waste of time to fix this. Imo > fbcon has 2 use-cases: > - display an OOSP. > - allow me to run fsck (or any other desaster-recovery stuff). 3. Show panics. Ensuring that nothing prevents the switch to fbcon and displaying the panic message is the reason why we haven't felt inclined to accelerate fbcon - it just gets messy for no real gain. For example: https://bugs.freedesktop.org/attachment.cgi?id=48933 which doesn't handle flushing of pending updates via the GPU when writing with the CPU during interrupts (i.e. a panic). -Chris -- Chris Wilson, Intel Open Source Technology Centre