Release WINE


i can use the terminal and some basic commands,but i lost it at "export the wine libs or gl passthrough to path" :( i'm not sure it something i can do.maybe i shoudl wait for a pnd version of it?
Click to expand...
Jep or take ingos image (8GB) when it is ready :) .
 
But first must i get this Running.


:) LinuxBochs can you please try the Unreal Tournament Linux X86 Demoversion with Qemu-I386 GL Accelerated?


I think its MUCH faster than in Wine x86 on Pandora :)
 
Are you sure? I thought qemu could not use open gl with wine at all. So it must be the linux version, at least when you trust the youtúbe title:

UT1 Pandora QEMU glshim
 
Last edited by a moderator:
^He said on IRC it was the Linux version of UT1.
 
Last edited by a moderator:
It's the Linux version. I don't have OpenGL working in any WINE programs except wglgears yet.

Was that Jazz Jackrabbit video with sound turned off?

mcobit - Sources required:

github.com/lunixbochs/qemu, ./configure --target-list=i386-linux-user

github.com/lunixbochs/glshim, branch proxy - you need src/libGL.so.1 and src/proxy/libglhost.so

github.com/lunixbochs/wine, branch arm - only required if you want to build a hybrid wineroot. Basically do a ./configure --prefix=/usr/local/wine/arm, symlink arm/lib/wine/*.exe.so to i386/lib/wine/
 
Lunixbochs may I ask how difficult it would be to implement the direct draw code?
 
DirectDraw acceleration is implemented (my libGL I've been working on for over a year now). It just crashes when you try to use it, and that's proving hard to debug :)
 
Very cool :) . Since you are in the boards and I can catch you: The sound output is probably quite costly in a qemu (since it is emulated code)). You said it could be catched too. Means this it could be handled in ARM code? Would this allow to emulate a faster cpu?
 
Last edited by a moderator:
rohezal said:
Very cool :) . Since you are in the boards and I can catch you: The sound output is probably quite costly in a qemu (since it is emulated code)). You said it could be catched too. Means this it could be handled in ARM code? Would this allow to emulate a faster cpu?
Click to expand...
That's what I'm working on right now.
 
lunixbochs said:
It's the Linux version. I don't have OpenGL working in any WINE programs except wglgears yet.


Was that Jazz Jackrabbit video with sound turned off?/
Click to expand...
Ah i see,then no speed Bonus for UT now....
....The Video with Jazz Jackrabbit was made with Qemu and Windows95 Image.runned smooth withous sound.


I think there is then a Bottleneck with Qemu-I386 and when Jazz Jackrabbit2 can work faster,then maybe UT too :)


Cool Work from you LB,i am underway to home now :)
 
The bottleneck is the cpu. The Pandora can emulate just a ~ 100 mhz cpu. UT needs a 233 cpu. The rendering is done by the gpu, so it is faster then your builder where the cpu has done the gpu stuff too (which means you only a fraction of the 100 mhz cpu). The sound is done by the emulated 100 mhz cpu too, which take lots of ressources. LB is trying to pass the sound code, the ARM cpu, where the full 1 Ghz cpu can do the sound (maybe even with support from hardware). Which means the emulated cpu gets again a bit faster.

If you want to play a game fullspeed :

Choose a game which uses the gpu more then UT (which uses the cpu a lot)

Pass the sound to the host OS, so the slow ~100 mhz cpu won't have to process it

Optimisation: Optimize floating point operations with neon code. Lots of game are doing around 32000 floating point operations per frame. With neon it would take only half the time. Maybe the most expensive functions can even completly be handled via a native arm lib, which catches like opengl the matrix multiplication calls. This could speed up things a lot. One target could be the direct x lib of wine, with the matrix stuff.
 
Last edited by a moderator:
Our biggest bottleneck CPU-wise is almost certainly floating point operations. I looked at optimizing the floating-point code of QEMU. We might be able to do some speed hacks in exchange for less FPU accuracy. Maybe an environment variable could toggle this at start.

NEON vectorization would be a harder task. You'd need to recognize that the source assembly was able to be vectorized. I don't think it currently supports SSE -> NEON translation, so maybe we could also hack some speed out of that.

I *think* UT was already running without sound. I turned the volume all the way down, but I can't guarantee sound calculation wasn't happening. I'd need to proxy OpenAL for UT's sound to be native.

rohezal said:
With neon it would take only half the time
Click to expand...
That's not very scientific. Earlier benchmarks of qemu-user estimated code performance at 1/4 speed and FPU performance at 1/10 speed.
 
Last edited by a moderator:
With neon it would take only half the time.

That's not very scientific. Earlier benchmarks of qemu-user estimated code performance at 1/4 speed and FPU performance at 1/10 speed.
Click to expand...
Sorry for that :( . I did not contribute anything to this great project, I should be more careful when I say things. But I liked the idea of Steven to use proxy dlls if it is possible, for directx math. I don't know if you could use "fake libraries" like the open gl syscalls. But if you could do something like catching the call of fake direct3d lib with the call

D3DXMatrixRotationX(&matRotateX, 3.14f);

and handle it in ARM space and write the results in x86 space, it could maybe save some cpu time. At least my phd told me, that in the past lots of game did the matrix multiplication without hard acceleration. If they used a lib for it, and the calls to this lib could be catched and executed by a native arm lib. And when this catched floating point operations are implemented in neon, it would be faster :) . 1x4 * 4x4 vector math are 16 floating point operations, maybe it is enough to be vectorized. When it is even possible to load external libs.
 
Last edited by a moderator:
I don't yet have a good path for loading WINE DLLs into the qemu host, so I can't use native versions yet. For it to work I might need to compile QEMU as a winelib app and run it inside WINE.

This means to run an x86 WINE app, you'd need to run: wine-arm qemu-i386 wine-i386 thing.exe
 
Idea Idea Idea :

LinuxBochs tried you different emulated Processors too?

When i renember Right can you emulate different Processors like Pentium or 486.

I had in the Past best results when i choose a CoreDuo (minimal more Speed)

The Idea i had for this was that Qemu use more Processor Instructions from the Pandora CPU

when choose a higher CPU Type and gain then little more Speed.

Next Idea:

Tried you Zeckensacks Glide Wrapper?

You can disable there much 3D Settings for Glide Games and gain maybe more Speed too in WineX86 3D

Next Idea:

Can you temporary disable some things we dont realy need like a

Qemu emulated Com Port/ParallelPort/Acpi Support/NetworkSupport and other Things?

Then have we it running in Core Mode with only the importants Things.

I will try it to install now on a fresh Slackware ;)
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

EvilDragon
Release Preview: Mupen64Plus 2.0 Video
4 5 6
Replies
111
Views
14K
matzesu
matzesu
Geca
Release BennuGD - Module Yeti3Dpro: Second Version
Replies
15
Views
5K
Geca
Geca
mcobit
Release Hex-A-Hop
Replies
18
Views
4K
Bachstelze
B
BAFelton
Release Sqrxz 4
Replies
10
Views
1K
F_Slim
F_Slim
iprice
Release [Rebirth Competition] Dino Defense
6 7 8
Replies
155
Views
16K
F_Slim
F_Slim
Back
Top