(no subject)

Guylhem Aznar wrote:
>>>Any news on your accelerated mq200 driver you presented on the simpad mailing
list?
>> sorry, I have been meaning to write an update on the status of the driver
>> on the simpad list for 3 months now, but somehow never did it.
> May I forward the message there?
Ok, wanted to send it there as well, but forgot it again. I'll put the
list on CC.

My Original Reply:
 There was problem with memory access, that I wrote about on the list.
I wasted 2 days trying everything, played with every setting that
sounded like it could help. But in the end nothing worked.  The
offscreen memory(the memory on the MQ200 not used for the display,
around 1.05MB) can't reliably be accessed by the CPU.  A turnaround
for this problem is quite hard (the display memory management would
have to be done through shared memory, which would require rewriting a
couple of Qt/E classes).

So offscreen bitmaps (as used by Konqueror) are not accelerated at all
(the code to support them is written, but hardly tested ). The rest
is working and quite stable (a off-by-one bug in the text drawing, scroll
bars are sometimes drawn in the wrong color, and very rarely the font
display gets corrupted and 1-2 Angus that might have been caused by
the driver). 

Because I did not feel any improvement using the MQ200 driver I wrote
a simple benchmark.

                          MQ200 driver  1.0.2  with Opt.  1.0.2 w/o Opt
Rectangle 10x10         :        482           598            1754
Rectangle 100x100       :        498          8681           12573
Pixmap 16x16            :        510           542             966
Pixmap 256x256          :      53799         52603           54067
Scroll                  :      14408        133557          160020
Text 8p 2 chars         :        632           724            3433
Text 8p 12 chars        :        879          1707            8969
Text 8p 40 chars        :       1788          4762           27111
Text 12p 2 chars        :        633           720            3414
Text 12p 12 chars       :        873          1717            8958
Text 12p 40 chars       :       1785          4748           27122

The time needed to execute 10000 operations is listed

In Opie 1.0.2 for Simpad Qt/E was compiled without optimization.
Mickey and Lorn Potter fixed this. So the values of 1.0.3 should be
the same as the values with optimization(the MQ200 is also compiled
with optimization).  For some parts the optimization really was quite
an improvement and the difference is easy to see in the Console
application it is a whole lot faster. On the other there is no visible
speedup from the MQ200 driver compared to the optimized Qt.

The MQ200 really shines in the rectangle and the the scroll (display
to display blit) benchmarks where it works alone.  The Pixmap benchmark
copies a pixmap from memory to display. In this case the CPU has to read
the data and supply it to the MQ200, I thought I could still achieve
some speed up compared doing everything on the CPU, but unfortunately
I was wrong(or the code is not optimal)

This is a very simple benchmark, real applications have a lot more 
overhead, so I said there is no noticeable speedup.
The case might be different for programs that constantly redraw the 
screen(like games, but the simpad is hardly a games machine).

When I started to write the driver I had high hopes to really make 
the gfx stuff faster. Alas that did not work out.
I did not have time to work on the driver in the last months, 
but anyhow I do not see what more I can do.

Guylhem Aznar:
> If I followed you, the driver only needs:
>  - pixmap code optimisation

Thinking a little bit more about the problem I am afraid that blitting
from main memory to screen with the help of the MQ200 can't be
optimized at all. The CPU has to read the pixmap, write it to the
MQ200 data pipeline register. That can't much faster when doing it all
on the CPU (which uses memcopy, which in turn probably uses the
LDM/STM opcodes to transfer the data quite quickly). For 16-bit mode
there is not much masking and shifting necessary (if at all), so that
the MQ200 does not help much.

Only if the pixmap is in the offscreen memory it could be made faster.

>  - find a good reliable way to access off screen memory

Yes, that is the main problem. I still do not know, if the problem is just
with my machine, or a general problem with the ARM<->MQ200 interface.
Would be nice if you could try out the test program
( http://home.arcor.de/rudolf.janz/mq ).

As I did not understand the underlying problem, I did not want to put
in kludges to just make things work. Reliability is quite important in
a video driver, as I noticed during many crashes and hangs during the
development :-)

If the problem can be solved reliably, additionally
during suspend one would need to put the MQ200
to sleep (go to D4 mode or whatever) instead of switching it off as
it happens right now, to keep the contents of memory. I looked at the
register documentation, should not be hard to set it up.

>  - and little bugfixes for the off by one, and color problems

These should not much of a problem. I simply wanted to solve the more
important problems first.


  Rudolf





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click