On Mon, 17 Nov 2008 13:54:55 +0800 John Lee <[EMAIL PROTECTED]> babbled:
> On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote: > > > > x's internals are definitely up for improvement - callium3d is there to try > > and fix this by providing a better more organised and better accelerated > > driver layer - but again - they aren't going to replace x... just clean up > > internals. what it means is - the rest of us can continue happily writing x > > apps and just "wait" for an improvement to pop out the pipeline. indeed x's > > internal acceleration layer could be improved. it has in the past > > (especially with xaa) proved an impediment if you have to code AT the > > driver layer. as such - x was originally designs (as a system - not > > specifically the xorg tree etc.) to allow full freedom to implement the > > internals of x any way you like - so as such if you wanted to spend the > > effort x could accelerate just about everything as long as hardware can do > > it, somehow - but the points at which that acceleration knowledge need to > > go into might be much higher up than xaa/exa. you'd have to write a > > "forked" x with all sorts of hooks higher up. - but it's possible... and > > then x client work as they always did - and get more use of the hardware :) > > MicroXwin ? > > http://www.microxwin.com/ > > "MicroXwin is binary compatible to the Xlib API. However it is niether > client server nor network oriented. Graphics operations are > implemented in the linux kernel via a kernel module. An open source > Xlib library sends graphics commands to the kernel. There is no > network overhead and no context switch from X client to X server. This > makes our solution smaller and faster than traditional X Windows." as such - context switching doesn't happen as often as people think.. if you write good x code - its' buffered. but as such this is an interesting solution - that is linux specific. not sure if it handles everything (window management, and not to mention enough of the modern extensions), but for gta03 (as this is framebuffer based) this could be a definite option. i'd say it'd be worth exploring. keeps compatibility AND should give you some speedup. not sure just how much day to day though. but the license seems... opaque - no idea what it is but it looks closed. but as such this would be another valid way of doing things with x. as such x apps just should avoid round-trip calls to x, so while they run they can do all their gfx ops WITHOUT a single round trip (thus no cache flush) and they only flush on final draw of everything - so just once per frame really (for the app). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community