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:
"Aaron J. Grier" ####@####.####
Date:
9 Jun 2004 18:45:26 +0100
Message-Id: <20040609174451.GR17401@mordor.unix.fryenet>
On Wed, Jun 09, 2004 at 02:30:47PM +0530, vishal wrote:
> 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.
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.
> 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.
> 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.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
