Re: X on O2, this time for real

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Mar 1, 2009, at 8:13 AM, Andrew Randrianasulu wrote:

> with latest bits (support for ARGB alpha masks) text under xfce's  
> desktop icons now visible (i screwed up my X install  slightly, and  
> was not sure if invisible text is my local problem or problem with  
> driver).

Ok, that worked with the old xf86 driver and XAA hack as well.

> Glxgears works for me too, ~20 fps with default window.

Hmm, I expected it to be slower since we need to DMA everything into  
the framebuffer scanline-by-scanline.

> Xfce terminal emulator was broken with enabled composite extension  
> (on screen it was like three window borders, menus with all the same  
> entries, strange cursor). Disabling composite "fixes" this. Overall,  
> driver works very well.

Hat's weird but I didn't pay any attention to the composite and damage  
extensions at all - they slow the whole thing down considerably so I  
have them disabled on most of my machines.

> about  CrimeReadPixmap (if i read/understand correctly, this  
> function (when implimented) should move data from video-memory to  
> system  memory, and un-tile it in process, in our case). What was/is  
> the problems with MTE? It hangs? move data without un-tiling it? Or  
> something else ...

MTE has weird alignment requirements for the X coordinate. When  
scrolling the console we avoid hitting them by always scrolling whole  
tile widths. The thing locks itself up if you try to copy anything  
that's not a multiple of 8 or 16 ( I forgot which ) pixels. It also  
does funny things if source or destination aren't aligned to 8 or 16  
( same as above ).
'locks itself up' as in 'never clears the busy flag and a hardware  
reset doesn't either so the console will lock up again on reboot'

> Michael, can you post things/problems you working on, so i will able  
> to do at least some testing? Of course, all O2 have same graphics  
> engine, and any real (unlike myself) developer will just write code,  
> without asking for guidance. Thanks for very intuitive register  
> names i understand at least some functions, but not sure what king  
> of bugs you see?

What really needs to be implemented it copying data out of the  
framebuffer. Shouldn't be hard at all, just reverse the direction of  
what CrimeWriteImageScanlines() does and look at newport's  
implementation for how to stick the result into a pixmap.
That's the easy part.
The more complicated problem is this - there are still occasional  
artifacts, for instance when you open xterm's menu you will see some  
pixels appear where they shouldn't be. That means someone or something  
writes into the framebuffer instead of going through the driver for  
whatever they're trying to do. What needs to be done here is to switch  
the framebuffer mapping back to read only ( cime_mmap() has a flag for  
that ), run the xserver in gdb and trigger the framebuffer write. Then  
have gdb look up where the write came from and fix it. The problem is  
that our gdb freaks out when it sees MIPS-III binaries so for this to  
work we need a userland compiled for MIPS-I. It will be considerably  
slower but gdb should work on it. The crime driver uses MPS-III  
instructions but its makefile makes sure gcc gets the right option  
just for the driver.
The really tricky problem is to track down Xrender problems. Look for  
instance at Enlightenment,  some text it tries to render appears with  
a black background instead of a transparent one. Enable some debugging  
output and find out what it's trying to do and why it fails.
Another small glitch I noticed is the Motif text cursor. It's not  
transparent even though normal text output is, when needed. We  
probably need to implement transparent blits which is going to be a  
pain in the arse - crime doesn't support color keying but it does  
support alpha testing.

> I 'benchmarked' mplayer (on gentoo linux, decoding only test, '-vo  
> null -ao null -quiet -benchmark' as mplayer's options) - 512x276 25  
> fps div3 + mp3 low-bitrate audio was a bit too much for my r5k (~  
> 111 sec for 100 sec fragment). Adding real video out will slowdown  
> things even more - so any kind of hw scaling and/or colorspace  
> conversion will help (as 'textured video' xv adapter, not as xv  
> overlay. Even hw without support for OpenGL rectangular textures can  
> do textured xv, or some sort of it [1]).

There is no scaling support in crime's 2D support. We could probably  
do that by using the texture engine but the format of the texture  
buffer is completely undocumented. If you feel like it stick some  
memory into the texture TLB ( should be the usual 64kB tiles ) and see  
if you can figure something out. That's not exactly trivial though, it  
needs kernel work.

> For start, i will build mplayer (from svn) for NetBSD, and see now  
> well it works with  just x11 vo. Very rough test for x11 XputImage  
> performance - x11perf -shmput500, i think.
>
> my pc (950 mhz Duron, agp radeon 9200se, EXA) scored at
>
> 800 reps @   7.4931 msec (   133.0/sec): ShmPutImage 500x500 square
>
> and for O2 i saw ~18  (but image was random noise). It was with  
> Xfree86, not with new xorg. I will try to run few x11perf tests, and  
> post numbers here.

I think playing videos on the O2 is pretty much pointless. Remember,  
it's a 200MHz R5k. Even the fastest CPU you can stick into the machine  
is only  400MHz R12k which might be fast enough to decode DVDs but  
probably not MPEG4. For MPEG and MJPEG we could use VICE ( basically a  
MIPS R4k with a SIMD unit running at 66MHz ) though. On IRIX it  
manages real time MJPEG on full size NTSC video, but drops frames as  
soon as there's too much noise. The O2's graphics backend supports a  
video overlay but it's tiled like the rest of the framebuffer so we'd  
have to DMA data in the same way, and I don't have enough  
documentation to use it. I think it mainly exists for the AV module to  
DMA data from analog or O2cam inputs directly to the screen.
On 2nd thought, there is some VICE code out there, I wonder id if can  
encode mp3 in real time, that would make it useful for recording from  
analog sources without clogging up the CPU.

> Any way to profile driver under NetBSD?  sorry for naive  
> question ... will dig documentation.

since you mean userland drivers - there's gprof. No idea if it works  
right on sgimips with MIPS-III binaries though.

> sorry for slowness on my side (each OS behaves differently, and i  
> want to learn [too?] many things in parallel. IRIX don't want to  
> mount my NFS, NetBSD still don't have konqueror installed (links  
> doesn't work with proxy for https - no yahoo mails! and no irc),  
> Gentoo has strange X problems, and i still learn their package  
> management system. All this is just configuration problems, but they  
> consume some time ... hope i will resolve most of them soon).

Konqueror works just fine here ( well, I didn't manage to build it on  
sgimips yet ) - even on sparc64 where anything gecko-based had endless  
troubles until a while ago. Takes ages to compile though.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSarEccpnzkX8Yg2nAQJA8Qf/TH5Gk3Shh0L7eN4so7Ne4I6fPI0yzSvl
BU/3bftvpJludAQTFkjD4kWOMD9Mo/TWDw7LnYJkDIsRIp8vXGLie2AHvmpG8L7D
+SvuDtqLKFu7Rv7c+R8vZsoLscpwws6+UVWSTMovtnm9FhGHkPHelchpMWA2LUU/
YqJJBaKgBXQA4kIPC9PXb/dYQW71qO9vzSl76I1DEIDE4If85fztRxnEQyDuzFSn
6jAh0CD6pMKuSzbd3XgsuBkJxe7S6g8WcQIaIy7cBaPa/nLA4XJEGHpJuuNJiTkM
6qMa3wPY7WRabP95zh/D5zpDD+6+o0AZSPFHZpH5hIkoWmAEYQ2WzQ==
=RN9F
-----END PGP SIGNATURE-----