From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel =?ISO-8859-1?Q?D=E4nzer?= Date: Thu, 23 Feb 2012 07:34:07 +0000 Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Message-Id: <1329982447.24753.15.camel@thor.local> 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: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Rob Clark Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Pawel Osciak , Marcus Lorentzon , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , linux-media@vger.kernel.org, Marek Szyprowski On Mit, 2012-02-22 at 10:28 -0600, Rob Clark wrote:=20 > On Wed, Feb 22, 2012 at 10:24 AM, Daniel Vetter wrote: > > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote: > >> > >> > > Imo we should ditch this - fb accel doesn't belong into the kernel= . Even > >> > > on hw that still has a blitter for easy 2d accel without a complet= e 3d > >> > > state setup necessary, it's not worth it. Chris Wilson from our te= am once > >> > > played around with implementing fb accel in the kernel (i915 hw st= ill has > >> > > a blitter engine in the latest generations). He quickly noticed th= at to > >> > > have decent speed, competitive with s/w rendering by the cpu he ne= eds the > >> > > entire batch and buffer management stuff from userspace. And to re= ally > >> > > beat the cpu, you need even more magic. > >> > > > >> > > If you want fast 2d accel, use something like cairo. > >> > > >> > Our conclusion on this is that we should not expose an explicit 2D > >> > acceleration API at the kernel level. If really needed, hardware 2D > >> > acceleration could be implemented as a DRM device to handle memory m= anagement, > >> > commands ring setup, synchronization, ... but I'm not even sure if t= hat's > >> > worth it. I might not have conveyed it well in my notes. > >> > >> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3 > >> possible accels; copyarea, imageblit, and fillrect. The first two coul= d 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 b= ig > > 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). > > > > It can do that quite fine already. >=20 > and for just fbcon scrolling, if you really wanted to you could > implement it by just shuffling pages around in a GART.. Keep in mind there are still discrete GPUs :), where scanning out from anything but VRAM may not be feasible, and direct CPU access to (especially reads from) VRAM tends to be very slow. However, for fbcon that can be addressed in each driver (as is done e.g. in nouveau), and has nothing to do with any userspace interface. --=20 Earthling Michel D=C3=A4nzer | http://www.amd.c= om Libre software enthusiast | Debian, X and DRI developer From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel =?ISO-8859-1?Q?D=E4nzer?= Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Date: Thu, 23 Feb 2012 08:34:07 +0100 Message-ID: <1329982447.24753.15.camel@thor.local> 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="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail.gna.ch (darkcity.gna.ch [195.226.6.51]) by gabe.freedesktop.org (Postfix) with ESMTP id 7BC449E7B6 for ; Wed, 22 Feb 2012 23:34:25 -0800 (PST) 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: Rob Clark Cc: Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Pawel Osciak , Marcus Lorentzon , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , linux-media@vger.kernel.org, Marek Szyprowski List-Id: dri-devel@lists.freedesktop.org T24gTWl0LCAyMDEyLTAyLTIyIGF0IDEwOjI4IC0wNjAwLCBSb2IgQ2xhcmsgd3JvdGU6IAo+IE9u IFdlZCwgRmViIDIyLCAyMDEyIGF0IDEwOjI0IEFNLCBEYW5pZWwgVmV0dGVyIDxkYW5pZWxAZmZ3 bGwuY2g+IHdyb3RlOgo+ID4gT24gV2VkLCBGZWIgMjIsIDIwMTIgYXQgMDQ6MDM6MjFQTSArMDAw MCwgSmFtZXMgU2ltbW9ucyB3cm90ZToKPiA+Pgo+ID4+ID4gPiBJbW8gd2Ugc2hvdWxkIGRpdGNo IHRoaXMgLSBmYiBhY2NlbCBkb2Vzbid0IGJlbG9uZyBpbnRvIHRoZSBrZXJuZWwuIEV2ZW4KPiA+ PiA+ID4gb24gaHcgdGhhdCBzdGlsbCBoYXMgYSBibGl0dGVyIGZvciBlYXN5IDJkIGFjY2VsIHdp dGhvdXQgYSBjb21wbGV0ZSAzZAo+ID4+ID4gPiBzdGF0ZSBzZXR1cCBuZWNlc3NhcnksIGl0J3Mg bm90IHdvcnRoIGl0LiBDaHJpcyBXaWxzb24gZnJvbSBvdXIgdGVhbSBvbmNlCj4gPj4gPiA+IHBs YXllZCBhcm91bmQgd2l0aCBpbXBsZW1lbnRpbmcgZmIgYWNjZWwgaW4gdGhlIGtlcm5lbCAoaTkx NSBodyBzdGlsbCBoYXMKPiA+PiA+ID4gYSBibGl0dGVyIGVuZ2luZSBpbiB0aGUgbGF0ZXN0IGdl bmVyYXRpb25zKS4gSGUgcXVpY2tseSBub3RpY2VkIHRoYXQgdG8KPiA+PiA+ID4gaGF2ZSBkZWNl bnQgc3BlZWQsIGNvbXBldGl0aXZlIHdpdGggcy93IHJlbmRlcmluZyBieSB0aGUgY3B1IGhlIG5l ZWRzIHRoZQo+ID4+ID4gPiBlbnRpcmUgYmF0Y2ggYW5kIGJ1ZmZlciBtYW5hZ2VtZW50IHN0dWZm IGZyb20gdXNlcnNwYWNlLiBBbmQgdG8gcmVhbGx5Cj4gPj4gPiA+IGJlYXQgdGhlIGNwdSwgeW91 IG5lZWQgZXZlbiBtb3JlIG1hZ2ljLgo+ID4+ID4gPgo+ID4+ID4gPiBJZiB5b3Ugd2FudCBmYXN0 IDJkIGFjY2VsLCB1c2Ugc29tZXRoaW5nIGxpa2UgY2Fpcm8uCj4gPj4gPgo+ID4+ID4gT3VyIGNv bmNsdXNpb24gb24gdGhpcyBpcyB0aGF0IHdlIHNob3VsZCBub3QgZXhwb3NlIGFuIGV4cGxpY2l0 IDJECj4gPj4gPiBhY2NlbGVyYXRpb24gQVBJIGF0IHRoZSBrZXJuZWwgbGV2ZWwuIElmIHJlYWxs eSBuZWVkZWQsIGhhcmR3YXJlIDJECj4gPj4gPiBhY2NlbGVyYXRpb24gY291bGQgYmUgaW1wbGVt ZW50ZWQgYXMgYSBEUk0gZGV2aWNlIHRvIGhhbmRsZSBtZW1vcnkgbWFuYWdlbWVudCwKPiA+PiA+ IGNvbW1hbmRzIHJpbmcgc2V0dXAsIHN5bmNocm9uaXphdGlvbiwgLi4uIGJ1dCBJJ20gbm90IGV2 ZW4gc3VyZSBpZiB0aGF0J3MKPiA+PiA+IHdvcnRoIGl0LiBJIG1pZ2h0IG5vdCBoYXZlIGNvbnZl eWVkIGl0IHdlbGwgaW4gbXkgbm90ZXMuCj4gPj4KPiA+PiBGYmNvbiBzY3JvbGxpbmcgYXQgYmUg cGFpbmZ1bCBhdCBIRCBvciBiZXR0ZXIgbW9kZXMuIEZiY29uIG5lZWRzIDMKPiA+PiBwb3NzaWJs ZSBhY2NlbHM7IGNvcHlhcmVhLCBpbWFnZWJsaXQsIGFuZCBmaWxscmVjdC4gVGhlIGZpcnN0IHR3 byBjb3VsZCBiZQo+ID4+IGhvb2tlZCBmcm9tIHRoZSBUVE0gbGF5ZXIuIEl0cyBzb21ldGhpbmcg SSBwbGFuIHRvIGV4cGVyaW1lbnQgdG8gc2VlIGlmCj4gPj4gaXRzIHdvcnRoIGl0Lgo+ID4KPiA+ IExldCdzIGJpdGUgaW50byB0aGlzIDstKSBJIGtub3cgdGhhdCBmYmNvbiBzY3JvbGxpbmcgdG90 YWxseSBzdWNrcyBvbiBiaWcKPiA+IHNjcmVlbnMsIGJ1dCBJIGFsc28gdGhpbmsgaXQncyBhIHRv dGFsIHdhc3RlIG9mIHRpbWUgdG8gZml4IHRoaXMuIEltbwo+ID4gZmJjb24gaGFzIDIgdXNlLWNh c2VzOgo+ID4gLSBkaXNwbGF5IGFuIE9PU1AuCj4gPiAtIGFsbG93IG1lIHRvIHJ1biBmc2NrIChv ciBhbnkgb3RoZXIgZGVzYXN0ZXItcmVjb3Zlcnkgc3R1ZmYpLgo+ID4KPiA+IEl0IGNhbiBkbyB0 aGF0IHF1aXRlIGZpbmUgYWxyZWFkeS4KPiAKPiBhbmQgZm9yIGp1c3QgZmJjb24gc2Nyb2xsaW5n LCBpZiB5b3UgcmVhbGx5IHdhbnRlZCB0byB5b3UgY291bGQKPiBpbXBsZW1lbnQgaXQgYnkganVz dCBzaHVmZmxpbmcgcGFnZXMgYXJvdW5kIGluIGEgR0FSVC4uCgpLZWVwIGluIG1pbmQgdGhlcmUg YXJlIHN0aWxsIGRpc2NyZXRlIEdQVXMgOiksIHdoZXJlIHNjYW5uaW5nIG91dCBmcm9tCmFueXRo aW5nIGJ1dCBWUkFNIG1heSBub3QgYmUgZmVhc2libGUsIGFuZCBkaXJlY3QgQ1BVIGFjY2VzcyB0 bwooZXNwZWNpYWxseSByZWFkcyBmcm9tKSBWUkFNIHRlbmRzIHRvIGJlIHZlcnkgc2xvdy4KCkhv d2V2ZXIsIGZvciBmYmNvbiB0aGF0IGNhbiBiZSBhZGRyZXNzZWQgaW4gZWFjaCBkcml2ZXIgKGFz IGlzIGRvbmUgZS5nLgppbiBub3V2ZWF1KSwgYW5kIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggYW55 IHVzZXJzcGFjZSBpbnRlcmZhY2UuCgoKLS0gCkVhcnRobGluZyBNaWNoZWwgRMOkbnplciAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LmFtZC5jb20KTGlicmUgc29mdHdh cmUgZW50aHVzaWFzdCAgICAgICAgIHwgICAgICAgICAgRGViaWFuLCBYIGFuZCBEUkkgZGV2ZWxv cGVyCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1k ZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8v bGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from darkcity.gna.ch ([195.226.6.51]:54465 "EHLO mail.gna.ch" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754036Ab2BWHkz convert rfc822-to-8bit (ORCPT ); Thu, 23 Feb 2012 02:40:55 -0500 Message-ID: <1329982447.24753.15.camel@thor.local> Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Rob Clark Cc: Daniel Vetter , Tomasz Stanislawski , linux-fbdev@vger.kernel.org, Sakari Ailus , Marcus Lorentzon , Pawel Osciak , Magnus Damm , dri-devel@lists.freedesktop.org, Alexander Deucher , Marek Szyprowski , linux-media@vger.kernel.org Date: Thu, 23 Feb 2012 08:34:07 +0100 In-Reply-To: References: <201201171126.42675.laurent.pinchart@ideasonboard.com> <1775349.d0yvHiVdjB@avalon> <20120217095554.GA5511@phenom.ffwll.local> <2168398.Pv8ir5xFGf@avalon> <20120222162424.GE4872@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Sender: linux-media-owner@vger.kernel.org List-ID: On Mit, 2012-02-22 at 10:28 -0600, Rob Clark wrote: > On Wed, Feb 22, 2012 at 10:24 AM, Daniel Vetter wrote: > > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote: > >> > >> > > Imo we should ditch this - fb accel doesn't belong into the kernel. Even > >> > > on hw that still has a blitter for easy 2d accel without a complete 3d > >> > > state setup necessary, it's not worth it. Chris Wilson from our team once > >> > > played around with implementing fb accel in the kernel (i915 hw still has > >> > > a blitter engine in the latest generations). He quickly noticed that to > >> > > have decent speed, competitive with s/w rendering by the cpu he needs the > >> > > entire batch and buffer management stuff from userspace. And to really > >> > > beat the cpu, you need even more magic. > >> > > > >> > > If you want fast 2d accel, use something like cairo. > >> > > >> > Our conclusion on this is that we should not expose an explicit 2D > >> > acceleration API at the kernel level. If really needed, hardware 2D > >> > acceleration could be implemented as a DRM device to handle memory management, > >> > commands ring setup, synchronization, ... but I'm not even sure if that's > >> > worth it. I might not have conveyed it well in my notes. > >> > >> 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). > > > > It can do that quite fine already. > > and for just fbcon scrolling, if you really wanted to you could > implement it by just shuffling pages around in a GART.. Keep in mind there are still discrete GPUs :), where scanning out from anything but VRAM may not be feasible, and direct CPU access to (especially reads from) VRAM tends to be very slow. However, for fbcon that can be addressed in each driver (as is done e.g. in nouveau), and has nothing to do with any userspace interface. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer