Michel Dänzer <[email protected]> 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"... -- [email protected]
pgpByTpCTDAYh.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
