First tests with Wine ARM - on OpenPandora

[ptitSeb]

Hi,

I am using an OpenPandora (use google if you want to know what's that), that use an Cortex-A8 processor and a Linux Angstrom distrib.

I successfuly compiled the latest v1.5.18 version of Wine and try to do some "Winemaker" compiling.

I use an emulator, from an old compuer called Mz800. Emulator is part of the "Takaeda Common Binaries" collection.

Winemaker need LibXML on Perl to convert vcproj file. Once installed, it works...
But the Makefile produced was on strange pagecode, not in UTF-8, and I had to convert "Ñ" to "/"...
Then, in the code, I have to add some "#undef new" in many .cpp files, to avoid an error at compile.
I also have to add "#define __assume(p) { }", on a file.
And I have to change the libraries as the default ones where not good.

Finally, it compile, and the software works !!!

I tried it with a correct ROM Bios and a Game Disc, and it works !

** But **

- I have no sound ! The DirectSoundCreate failed with an error 8889000F. I tried the winecfg, and the Test Sound makes funny noise but no proper sound. Asla is selected. I use asla on other software with no problems.
- performance is really slow. I have no OpenGL on the Pandora (GL-ES, but Wine don't use it), so no DirectX9, plain GDI. This machine emulated is not that powerful, just a Z80, And I have just between 20% to 40% real speed (on a 1GHz ARM processor), but not sure of the source of the bottleneck.

Any advice is welcome, I will continue my experiments...

[André H.]

Hi,
winemaker is still just a starting point, it can't handle every strange thing. so you did it right and didn't gave up, i'll have a look at that utf8 thing.

8889000F is AUDCLNT_E_ENDPOINT_CREATE_FAILED, you can have a look in winealsa.drv to find possible reasons, it's mostlikely the best when you debug that yourself, might be hardware specific.
I'm not sure if we can use GL-ES for Wine, but i also can't test it right now, i always fail to set it up on my pandaboard.

[ptitSeb]

Thank you for your answer.

I have recompiled Alsa lib, just to be sure, et voilà ! it works with sound now !

About speed, I also tried an other emulator of the same computer (mz800em), that is linux native. And it is also a bit slow (less, but it also less complex). So this kind of emulator must be more demanding than I first thought. I have to dig a bit now to try optimize this, at 5 fps, it's not usable. But I have my first "Windows" software recompile on the OpenPandora, and that's great !

[André H.]

Thank you for your answer.

I have recompiled Alsa lib, just to be sure, et voilà ! it works with sound now !

do you know if you did something different than the packager?

But I have my first "Windows" software recompile on the OpenPandora, and that's great !

That's pretty cool, yes. Did this years ago at the beginning of my ARM work with Putty

[ptitSeb]

I haven't done anything special. Just recompile Alsa, may be restart my environnement (I don't remember).

I will try to compile MesaGL to add OpenGL & DirectX to Wine, maybe, even with the Software implementation of Mesa, I will gain a few fps...

[ptitSeb]

I did a quick test, and remove the call to the main "BitBlt" function of the program. Obviously, the screen stay black, but the "virtual" FPS are now much higher, aroud 45fps. So the BitBlt itself (the bitmap has a size of 640x400) is reponsable for at least 25 fps drop. I find it huge !
Do the math, 45 fps means 1 cycle is done in 22 ms, and the BitBlt alone add a full 80 ms do that ?! Knowing that the Bitmap that is blited is drawn fully at every cycle, something is taking to much time in BitBlt.

Is there a way to optimize that ?

[André H.]

How is the situation on x86? I doubt this is ARM specific and for most developers it's easier to track that down on x86, maybe with a bug ticket.

[ptitSeb]

I have to setup a VM with that. I experiment mainly on the Pandora.
I will also try to recompile Wine with more options, maybe I missed an important one (wine take 6Hrs to compile on Pandora, better be sure of the options before "make").

[André H.]

a VM for x86(_64)? are you on Windows?
6h sounds reasonable, but i'm much quicker on my pandaboard still you can crosscompile

[ptitSeb]

Yes, I'm on Windows. An OpenPandora is not a pandaboard, if I have googled correcty. It is a bit slower I think.
I have a VM with a x86 linux ont it, and I can (try) to cross copile with it. But, well, my environment is not setup correctly, and most a the time a compile x86 binary

Well, It compile now, my Pandora has all the night for that... Will check tomorow if my BitBlt are faster. I have compile MesaGL also, so I will try Directx9 Blits, but I'm not optimistic on this, because I doubt the MesaGL with Soft resteriser by faster than plain simple Blits...

[ptitSeb]

A quick update. MesaGL Soft is slow. So I have DirectX now, but it slows down to 2 fps when I use DirectX. To bad, as it just do some 2D Blitting...

[ptitSeb]

It seems that BitBlt in fact call StrechBlt. What I don't know, yet, is if StrechBlt has some special cases to do "Fast" Blit if no strechning is needed...

[ptitSeb]

So, I have taken the newest 1.5.19 version of Wine, and also upgrade my environment to GCC 4.7.2 (from 4.6.3). I have lost sound again
I have a DirectSoundCreate failed with error 0x80070057 (E_INVALIDARG I think)

*EDIT* In fact, error code is 0x8889000f again :'(. Recompiled alsa and it didn't work this time


But it does seems faster. Have to get back sound before doing bench...

[ptitSeb]

I have tracked down my problem with the sound. I fact, it tries to initialize Alsa with Float 32bits formats. I don't think my platform can handle this, plus, I try to avoid Float as they are slow on ARM with softfp (even activatig float hardware, I still use softfp).

Do someone know of a way to not enable Float? I have to check with the software I run, but I'm pretty sure it want Integer !

The PCMWAVEFORMAT struct is called with
wFormatTag = WAVE_FORMAT_PCM;
nChannels = 2;
wBitsPerSample = 16;
nSamplesPerSec = sound_rate; // this is selectionnable by menu, default is 48000
nBlockAlign = nChannels * wBitsPerSample / 8;
nAvgBytePerSec ) nSamplesPerSec * nBlockAlign;

I don't see float, so it must by the DSound.dll.so itself that choose Float.

[ptitSeb]

Ok, found it. I recompile Alsa with the option "--have-softfloat" in the ./configure, and now, DirectSoundCreat take Integer 16bits, no more Float 32bits. It still choose 48kHz even when the windows side choose 22050Hz, and that's bad for the performances... But it works, again...

[ptitSeb]

So, does anybody know if this can be tweaked somehow. How to reduce the buffer mix rate, or even make it dynamicly adjusted?

[juan]

you should ask on wine-devel mailing list: http://www.winehq.org/mailman/listinfo/wine-devel

[ptitSeb]

I'll try.

[juan]

you got mail

[ptitSeb]

Just for info, I ported another games on the OpenPandora using Wine. It's XMSol, a Solitaire Card Game. The games works very well, and it was almost a plug'n play operation. No makefile was supplied, so I use the "create from scratch" ability of Winemaker, and I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

And it compile and run nicely.

There is not DirectX, so it's light on the system, that's help.

Ok, just a thing is missing, the Help, which is based on CHM, so it show a White page on ARM (complaining on the console that gecko-arm doesn't exists yet, or something like that).

[André H.]

Just for info, I ported another games on the OpenPandora using Wine. It's XMSol, a Solitaire Card Game. The games works very well, and it was almost a plug'n play operation. No makefile was supplied, so I use the "create from scratch" ability of Winemaker, and I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

And it compile and run nicely.

There is not DirectX, so it's light on the system, that's help.

Nice to hear, always a good motivation. Could you please gather winelib ports to ARM somewhere? Maybe even with source and binaries?

Ok, just a thing is missing, the Help, which is based on CHM, so it show a White page on ARM (complaining on the console that gecko-arm doesn't exists yet, or something like that).

yes, wine-gecko still not ported, see http://wiki.winehq.org/ARM
anyway, there are native linux chm viewers

[ptitSeb]

Just for info, I ported another games on the OpenPandora using Wine. It's XMSol, a Solitaire Card Game. The games works very well, and it was almost a plug'n play operation. No makefile was supplied, so I use the "create from scratch" ability of Winemaker, and I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

And it compile and run nicely.

There is not DirectX, so it's light on the system, that's help.

Nice to hear, always a good motivation. Could you please gather winelib ports to ARM somewhere? Maybe even with source and binaries?

No problem.

The OpenPandora use the "PND system" to provide EndUser an easy system to Add/Remove software. You jet put the "PND" file in a folder on your SDCard and you good to go.

The xmsol PND can be found here: http://repo.openpandora.org/?page=detai ... ol-ptitseb

In fact, a PND is a squashfs ISO file (plus an xml description file and a png icon appened to the ISO, and renamed as ".pnd"). So it can be mounted on linux, or open on Windows with 7zip.

The binary is inside the PND (compile with -mcpu=coratex-a8 -mfpu=neon -mfloat-abi=softfp), as well as the sources.

[sle85276]

I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

What about sending a patch to [email protected] . Than you don't need to add it next time.

[ptitSeb]

I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

What about sending a patch to [email protected] . Than you don't need to add it next time.

Well, I add that definition in the source code of the software I was compiling. I don't really know where I should put that in the winelib files. Do you know where it should go?

[André H.]

I just had to add
#define UInt32x32To64(a, b) ((ULONGLONG)(a)*(ULONGLONG)(b))

What about sending a patch to [email protected] . Than you don't need to add it next time.

Well, I add that definition in the source code of the software I was compiling. I don't really know where I should put that in the winelib files. Do you know where it should go?

it should go into include/winnt.h, i'd place it before /* Defines */ (line 577)
But you should fix your definition first and also add at least Int32x32To64