[PATCH 0/4] fb support for 8bpp bitmaps

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> But why are you putting so much effort into trying to share storage
> between GPU and CPU for bitmaps, given that SNA has apparently proved
> such sharing is not beneficial overall even on Intel GPUs?

Did you look at how 'hard' getting GPU-acceleratable depth-1
pixmaps was?

 fb.h        |  107 ++++++++++++++++++++++++++++++++++++++++-----------------
 fbbltone.c  |  111 +++++++++++++++++++++++++++++++-----------------------------
 fbcopy.c    |    3 +
 fbfill.c    |    2 -
 fbgc.c      |   10 ++++-
 fbglyph.c   |    2 -
 fbimage.c   |   33 ++++++++++++++---
 fbpixmap.c  |    8 +++-
 fbpush.c    |   12 ++++--
 fbscreen.c  |    9 ++++
 fbstipple.c |   10 +++--
 wfbrename.h |    1 
 12 files changed, 204 insertions(+), 104 deletions(-)

If that gets us on the path to using 8bpp for bitmaps so that we can
draw them with the GPU, that seems like a win to me. Again, the goal is
to incrementally move to a model where the GPU can draw everything, but
move in a way where performance compared to the current server is
comparable through the whole process.

> It seems more useful to spend effort on maintaining separate persistent
> CPU storage for software fallbacks, which has proven effective in EXA
> and SNA.

That's a huge waste of time if your goal is to never touch pixmaps with
the CPU at all. The only reason you should ever be migrating pixmaps is
if you have a non-UMA machine and simply run out of GPU-accessible
storage.

"software fallbacks" is just another name for "failure"...

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140115/89f650b9/attachment.pgp>