no :) not confused - just dealign with raw scheduling right now
(basicalyl i do all my gfx work client-side in software in memory
buffers - X is only involved in a final dump to a drawable
(XShmPutImage) - until it gets to that stage it haqs to do the image
building (blend data togeteher, scale images etc) then hit the
ARGB->bit depth converstion code that converts the buffer to drawable
depth - then a final phase of display that involves X - so X will be
scheduled then only if other processes are pummelign it with requests
(in which case that's ok - you're machine is busy - we'll just have to
contend for cpu - so be it)
i know that as long as i do a reasonable numebr fo x requests and keep[
them mainly asyncronous i can max ou a 2cpu system anyway - but the way
the system works is that its all software client side so having more
than one cpu working on generating the data before it hits X would be
useful. of course the opengl acceleration planned (as long as i can do
32bit pbuffer textures specced for opengl 1.2 but curently not
implimented in Xfree86 3.9) will blitz any speedups i can get via
multiple treads - but i'd still like to imporve performance for those
on smp machines without an opengl accelerated card :)
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com
raster@enlightenment.org raster@linux.com
raster@zip.com.au
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/