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:
14 Jun 2004 10:13:40 +0100
Message-Id: <016b01c451ef$c6d8b120$e900a8c0@VISHALISOFTT>
Hi Aaron,
Thanks a lot!! You have been immensely helpfull! I hope i learn some more
things from you in th course of our stay out here!
Now.....Getting back to the problem at hand...:-)
> it may be worthwhile to examine linking the VNC client directly with
> nano-X. this can avoid a select over a socket between the two, and
> avoid copying graphic data over the socket. the overhead then becomes
> function calls rather than socket operations.
hmm... linking the VNC client with nano-X would be a good try. I have
found that the socket writes are taking more than 80% of the total
processing time of a nano-X - VNC run. How much effort do you think
implementing this will take? Any pointers on how i could about it? I guess
what i could do is integrate the vnc main() code into nano-X main() and
set selects on the fds used in both. I think i know what needs to be
done..but i am still very fuzzy about the approach i should take.
Some one was suggesting i change the socket types used, to UDP. do you
think that would make any difference?
> > 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.
>
> if that's the case, you might be able to put an S1D13506 in there; its
> pinout is almost identical to the S1D13505, and it has a BitBLT engine
> for doing video memory copies. the memory map of the 506 is a little
> different than the 505, and it requires different code, but I can give
> you my current device driver (which handles both) if you're interested.
hmm...wat is the kind of performance improvement we could expect by
replacing with the S1D13506 ? Any idea?
> > back to the optimisation, could yu suggest some possible places in
> > Nano-X which i might have to give special attention for optimising?
>
> if you're currently running the generic 16bit framebuffer driver, my
> hunch is that VNC will be pounding on the gen_fillrect() and
> linear16_blit() routines the hardest. you could write your own
> implementations of these functions and then use whatever DMA or zero-
> overhead looping instructions your processor has to speed them up: use
> 32bit operations to move two 16bit pixels at a time, for instance. (but
> be aware of alignment issues for the beginning and end points.)
> start with a copy of src/drivers/scr_fb.c, and put rewritten copies of
> gen_fillrect() and linear16_blit() from src/drivers/fblin16.c in there.
> get rid of the call to select_fb_subdriver(), and use your own subdriver
> structure with your custom blit and fill routines instead.
I m looking at the above right now....
regards,
Vishal
