Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
daniel at ffwll.ch
Wed Feb 22 08:24:24 PST 2012
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.
Flamy yours, Daniel
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the dri-devel