nanogui: Nano-X running on BF531 uClinux board: extermely slow updates
Subject:
Re: [nanogui] Re: Nano-X running on BF531 uClinux board: extermely slow updates
From:
"vishal" ####@####.####
Date:
9 Jun 2004 10:01:20 +0100
Message-Id: <010c01c44e00$4231c120$e900a8c0@VISHALISOFTT>
Hi Aaron,
Thanks a lot for the reply.
I have been profiling the functions called inside nano-X / VNC. It was
seen that the select() system call was taking an usually long time & also
was being called some 11,400 times for every update. I managed to get the
number of select() invocations, and the updates begun happenning 1.5 secs
faster.
Also, I was wondering if the transfer of pixel data from the vnc client
to the Nano-X server could have a signinficant impact on the speed of
execution? Thats where the idea of using a direct-to-framebuffer-vnc somes
into the question, since unix sockets traditionally take quite some time.
Actually we are using the Epson S1D13505 on our blackfin board too!. :-)
so i guess you can help me out when i ask you about the best h/w setup for
this chip for use at 640x480, 16bpp. dont have the exact h/w details abt
that tho.
back to the optimisation, could yu suggest some possible places in
Nano-X which i might have to give special attention for optimising?
regards,
vishal
----- Original Message -----
From: "Aaron J. Grier" ####@####.####
To: ####@####.####
Sent: Tuesday, June 08, 2004 10:37 PM
Subject: [nanogui] Re: Nano-X running on BF531 uClinux board: extermely slow
updates
> On Mon, Jun 07, 2004 at 02:43:15PM +0530, vishal wrote:
> > Does anybody have any benchmarks for running Nano-X smoothly....i mean
> > the kind of preocessing power required..or is 75MHz sufficient?
>
> I run with a 25MHz 68331. the platform started out with an Epson
> S1D13505 (used to be SED1355). those was the nano-X 0.89-pre7 days, and
> things were pretty slow until we started optimizing things for our
> platform. a few of them have since made it into the mainline source.
>
> > I would loike to know if there is something that could be done inside
> > Nano-X to optimise it futher, or whether it could be a limitation of
> > our hardware itself.
>
> you need to do some profiling and determine what calls are taking the
> most time.
>
> also helpful would be some raw video bandwidth tests, to give you an
> idea of the absolute fastest speed you can go. test video to video,
> video to main memory, and main memory to video copy speeds. use
> zero-overhead looping if your CPU supports it.
>
> > I have also been asked to look at alternative options to Nano-X,
> > specifically directfb with a directfb vnc client. How does nano-X
> > compete with programs of a similar nature? I would really appreciate
> > it if anyone would suggest any ideas.
>
> I belive VNC makes heavy use of blitting; if you can get the blit
> routines sped up, I suspect your performance will increase.
>
> --
> Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
