nanogui: Thread: CLPS7500FE chip is slowly

I cross compile nano-X to arm arch. now it can run on cirrus logical 7500 chip(the OS is arm linux) , but it was slowly to refresh the screen. and the color is uglily. so what is the lowest cpu requiement, should  I use SA1100? and what is the default nano-X color setting ?

thanks.

: I cross compile nano-X to arm arch. now it can run on cirrus logical 7500
chip(the OS is arm linux) , but it was slowly to refresh the screen. and the
color is uglily. so what is the lowest cpu requiement, should  I use SA1100? and
what is the default nano-X color setting ?

Use the SA1100, there's a version that runs at 206Mz.

The default color setting for Nano-X is whatever you
link in with the src/engine/devpal{1,2,4,8}.c files,
and then what the framebuffer is set to.

If you don't like the colors, you might want to change
the palettes.  On the other hand, I suspect your kernel
probably doesn't support the set palette ioctls.  Check
src/drivers/scr_fb.c for details.

Regards,

Greg

> -----Original Message-----
> From:	Greg Haerr ####@####.####
> Sent:	Friday, December 01, 2000 5:33 AM
> To:	Tony Hoo; nanoX-MailList
> Subject:	Re: CLPS7500FE chip is slowly
> 
> : I cross compile nano-X to arm arch. now it can run on cirrus logical 7500
> chip(the OS is arm linux) , but it was slowly to refresh the screen. and the
> color is uglily. so what is the lowest cpu requiement, should  I use SA1100? and
> what is the default nano-X color setting ?
> 
> Use the SA1100, there's a version that runs at 206Mz.
	[Simon Wood]  
	Now now Greg - are you being a naughty boy???? You can't (shouldn't) get around slow performance by throwing more power at it, you'll end up with overly complicated, bloated code.... just like M$!!!! I mean that shouldn't we be keen on improving the performance for these lower power machines......

	What speed is the 7500 running at?

	There are a few areas which could slow it down. One (that I know of) is the switching of Landscape/Portrait mode - one of these is straight through (without computation) this might speed you up, though will leave you with a dilemma whether to fix or turn you screen on its side....
	Simon Wood.

Simon -

Don't be so quick to judge Greg.  The mechanics behind a screen refresh
are often processor intensive, and sometimes, you just need a faster
processor.
In M$ defense, I doubt that much of their system bloat had to do with
the low level drawing routines.  But even the open source projects
suffer from slow processors.  Did you ever run XFree86 4.0 on a 100 Mhz
system? (its bad enough on my 200 Mhz machine).

Maybe the 7500 doesn't have a assembly instruction to move a block of
memory.  If it doesn't, then the system is reduced to a for loop for
blilting.  No amount of optimization will help with that.

It is my contention that the low level framebuffer routines are very
good and very fast (unlike our poor X11 drivers... :( ), and that we can
go head-to-head with any graphics engine out there.  But if you feel
that the framebuffer routines could benefit from some optimization,
please feel free to give us a list of routines that need work. 
Sometimes, you might be able to lock onto something that the rest of us
missed.  This of course, is the beauty of open source.

Happy hacking!
Jordan

Simon Wood wrote:
> 
> > -----Original Message-----
> > From: Greg Haerr ####@####.####
> > Sent: Friday, December 01, 2000 5:33 AM
> > To:   Tony Hoo; nanoX-MailList
> > Subject:      Re: CLPS7500FE chip is slowly
> >
> > : I cross compile nano-X to arm arch. now it can run on cirrus logical 7500
> > chip(the OS is arm linux) , but it was slowly to refresh the screen. and the
> > color is uglily. so what is the lowest cpu requiement, should  I use SA1100? and
> > what is the default nano-X color setting ?
> >
> > Use the SA1100, there's a version that runs at 206Mz.
>         [Simon Wood]
>         Now now Greg - are you being a naughty boy???? You can't (shouldn't) get around slow performance by throwing more power at it, you'll end up with overly complicated, bloated code.... just like M$!!!! I mean that shouldn't we be keen on improving the performance for these lower power machines......
> 
>         What speed is the 7500 running at?
> 
>         There are a few areas which could slow it down. One (that I know of) is the switching of Landscape/Portrait mode - one of these is straight through (without computation) this might speed you up, though will leave you with a dilemma whether to fix or turn you screen on its side....
>         Simon Wood.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

> It is my contention that the low level framebuffer routines are very
> good and very fast (unlike our poor X11 drivers... :( ), and that we can

The X11 low level frame buffer routines are _very_ good actually. Especially
and in fact if anything more so for single issue processors of the past (and
the current embedded world). They do a lot of loop unrolling.

You might want to browse the cfb code. Once you understand how the Duffs
device and blitter macros unroll you'll be impressed

Nanogui's rendering code is nowhere near as good

Actually, I was refering to the Microwindows interface to X11 (Greg and
Jason know what I'm talking about). 
I know that the X11 drivers themselves are most excellent.  

Jordan

Alan Cox wrote:
> 
> > It is my contention that the low level framebuffer routines are very
> > good and very fast (unlike our poor X11 drivers... :( ), and that we can
> 
> The X11 low level frame buffer routines are _very_ good actually. Especially
> and in fact if anything more so for single issue processors of the past (and
> the current embedded world). They do a lot of loop unrolling.
> 
> You might want to browse the cfb code. Once you understand how the Duffs
> device and blitter macros unroll you'll be impressed
> 
> Nanogui's rendering code is nowhere near as good

: > Use the SA1100, there's a version that runs at 206Mz.
: [Simon Wood]
: Now now Greg - are you being a naughty boy???? You can't (shouldn't) get
around slow performance by throwing more power at it,

Simon, thanks for making me laugh.  Yes, I suppose I was getting a bit
lazy by just stating to use an 1100 when there's all sorts of good work
trying to get other chips working well ;-)

I agree with your "throwing more power at it," except that it won't
result in overly complicated code.  Instead, unrolling loops and trying
to make slower processors work better results in overly complicated
code in graphics ;-)

Regards,

Greg


 you'll end up with overly complicated, bloated code.... just like M$!!!! I mean
that shouldn't we be keen on improving the performance for these lower power
machines......
:
: What speed is the 7500 running at?
:
: There are a few areas which could slow it down. One (that I know of) is the
switching of Landscape/Portrait mode - one of these is straight through (without
computation) this might speed you up, though will leave you with a dilemma
whether to fix or turn you screen on its side....
: Simon Wood.
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:

: Nanogui's rendering code is nowhere near as good

Sigh ;-(  Unfortunately, Alan is right.  The Microwindows framebuffer
routines are written to be simple, and simple in graphics is usually
slower.  In order to be blazingly fast in graphics, every possible
drawing mode, as well as inner loops, need to be separately
coded.  This is one of the reasons X is big.  And I think that's also
one of the reasons that Windows is big.  (Of course, the bloat in
windows is probably only 10% in the GDI screen drivers, everywhere
else it's to support the damned MFC and other 4980 API entry points.)

Having said that, with small screens, it's usually not a big issue
since fewer pixels are being pushed.

The real demonstration is running Microwindows on ELKS 8086 Linux.
Then you'll see how hurtfull it is to try to push 640x480 pixels on 
an 8088...  Asm routines are a must.

Regards,

Greg

> Sigh ;-(  Unfortunately, Alan is right.  The Microwindows framebuffer
> routines are written to be simple, and simple in graphics is usually
> slower.  In order to be blazingly fast in graphics, every possible
> drawing mode, as well as inner loops, need to be separately
> coded.  This is one of the reasons X is big.  And I think that's also

Only for older designs of cpus (and thus embedded stuff sometimes). On modern
superscalar processors it becomes a loss ironically. 

> Having said that, with small screens, it's usually not a big issue
> since fewer pixels are being pushed.

And the size of code is valuable on a PDA too

>