On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
quoted
quoted
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
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48