So far, on the FR, I remain to be convinced that the use of X is the
critical performance issue. In any event, the main issue with
optimization efforts is whether they can proceed faster than the
introduction of better hardware. If a 400 Mhz machine is "too slow",
will a 1 Ghz machine be fast enough? Will anything be fast enough?
Apparently, from the history of desktops, the answer is no!

My own experiments with the FR lead me to believe that memory access and
peripheral access are more significant than X performance, but I have
yet to do the tests and the math.

Carsten Haitzler (The Rasterman) wrote:
> 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 ?
>> "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).

Iain B. Findleton
Tel: 514-457-0744

Openmoko community mailing list

Reply via email to