[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
CLPS7500FE chip is slowly
From: "Tony Hoo" ####@####.#### Date: 30 Nov 2000 03:06:00 -0000 Message-Id: <00bb01c05a7b$201331e0$354f44d3@HuXianGang> 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: "Greg Haerr" ####@####.#### Date: 1 Dec 2000 05:31:13 -0000 Message-Id: <02b001c05b58$3ac96260$15320cd0@gregh> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: CLPS7500FE chip is slowly
From: Simon Wood ####@####.#### Date: 1 Dec 2000 08:58:34 -0000 Message-Id: <44632C76B97BD211AF6B00805FADCAB202D738EA@exchange.saltaire.pace.co.uk> > -----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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: Jordan Crouse ####@####.#### Date: 1 Dec 2000 15:14:07 -0000 Message-Id: <3A27C11E.26AD5C8C@censoft.com> 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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: Alan Cox ####@####.#### Date: 1 Dec 2000 15:40:21 -0000 Message-Id: <E141sKw-0000Nf-00@the-village.bc.nu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: Jordan Crouse ####@####.#### Date: 1 Dec 2000 15:45:43 -0000 Message-Id: <3A27C880.631302E0@censoft.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: "Greg Haerr" ####@####.#### Date: 1 Dec 2000 17:12:11 -0000 Message-Id: <057401c05bba$283ffa20$15320cd0@gregh> : > 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: ####@####.#### : | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: "Greg Haerr" ####@####.#### Date: 1 Dec 2000 17:25:21 -0000 Message-Id: <05c701c05bbb$ff513d20$15320cd0@gregh> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: CLPS7500FE chip is slowly
From: Alan Cox ####@####.#### Date: 1 Dec 2000 18:31:44 -0000 Message-Id: <E141v0W-0000ZV-00@the-village.bc.nu> > 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 > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |