Release WINE

[lunixbochs]

I hacked that into function. Everything's a little... off

My implementation is probably pretty bad. There are pieces sticking out of glxgears. Unreal Tournament just renders a white screen.

However, it doesn't crash. That's promising.

http://bochs.info/~aegis/qemu-fpu - code is in the fpu branch at https://github.com/lunixbochs/qemu

I'm seeing a noticeable improvement in unproxied alsa payback:



aegis@rebirth:~$ time qemu-i386 ./aplay piano2.wav 
Playing WAVE 'piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo


real 0m35.232s
user 0m33.461s
sys 0m0.336s

aegis@rebirth:~$ time qemu-fpu ./aplay piano2.wav 
Playing WAVE 'piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo


real 0m16.935s
user 0m14.992s
sys 0m0.289s

Versus proxied:


aegis@rebirth:~$ time qemu-i386 ./aplay piano2.wav
Playing WAVE 'piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real 0m6.684s
user 0m0.453s
sys 0m0.109s
aegis@rebirth:~$ time qemu-fpu ./aplay piano2.wav
Playing WAVE 'piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real 0m6.684s
user 0m0.414s
sys 0m0.148s





The software-rendered 3d Jazz2 intro is also far smoother.

This shows us we can potentially get a 2x improvement on FPU performance by using native floating point. Probably more if we put NEON behind the SSE core. I'm probably not going to invest much more time into it however.

 

[Rockthesmurf]

So are they your own implementations of softfloat-native.c/.h (on the fpu branch of https://github.com/lunixbochs/qemu)? If so, it might be worth trying one of the existing native implementations. If you are already using one of the existing ones then I guess there is some tricky debugging to work out what is going wrong. I couldn't find much information about the native soft float modules (benchmarks, write ups, etc.) however I did notice that on the main QEMU page is states:

QEMU generic features:

• Floating point library supporting both full software emulation and native host FPU instructions.

But I couldn't see how you enable/configure this, although I haven't actually downloaded the source, only browsed the online tree. Your bench for wave playback is promising.

Still, there is some hope Diablo 2 and Half Life may run a little better than we have seen so far

 

[lunixbochs]

The Diablo 2 demo was without graphics acceleration. We can potentially get it to full speed.

This softfloat-native.c was the one you linked, plus hacks to make it compile against current Qemu.

I see much more recent activity against softfloat-native: http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01727.html

Looks like it was removed in this patch: http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg02533.html

 

[Linux-SWAT]

Was late on this thread. lunixbochs, seems like you'll be the next #1 in Dragon Box competition ^^.

I'd be curious to see some Starcraft 1 video with those latest improvements.

Also, if someone can provide me clear instructions, i can include the public parts in SL4P.

 

[mcobit]

Starcraft might not run better right now as there is no direct draw accelleration in this build right now. Only improvement could be that it doesn't need a host system anymore with the wine implementation.


Seeing that halflife wasn't improved much, I guess there will not be a major speedup right now.


But hey, lunixbochs surprised us more than once

 

[Linux-SWAT]

You mean not better than "normal" qemu ?

 

[mcobit]

I guess. Didn't try yet.

 

[Linux-SWAT]

For information, under qemu SC/BW is actually 80% of the normal speed.

I hope for even small improvements ;^) .

 

[lunixbochs]

If nothing else, you still get sound at no cost.

 

[Linux-SWAT]

As in "no cost beer" ?

 

[mcobit]

That would be really an improvement as without any sound it is really close to fullspeed on a GHz unit.

 

[lunixbochs]

As in "no cost beer" ?

As in no CPU cycles.

 

[Askarus]

Just in case you didn't check yet: WINE 1.7.1 is out.

 

[lunixbochs]

Unless I missed a relevant wined3d improvement, nothing too exciting for us there.

I'm interested to see if the Diablo II or Half Life demos work with qemu-fpu

 

[rohezal]

well with the faster qemu verson, faster floating points and without sound overhead it looks very promising for star craft

 

[Rockthesmurf]

I see much more recent activity against softfloat-native: http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01727.html


Looks like it was removed in this patch: http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg02533.html

I asked over in the QEMU IRC channel what the status of the native FPU support is, and unfortunately:

<scraft> I have been watching the progress of QEMU being used on an ARM based handheld. Significant performance increases are visible when hacking in some of the old native FPU code (which has now been removed from the QEMU source tree). I wondered if anyone had any information why it was removed?


<pm215> it wasn't accurate, and two different configs and associated chunks of code are a maintenance burden


<scraft> pm215: based on this I guess it is unlikely a native FPU code path would be added once again at a future point?


<pm215> correct

This is obviously a shame from our point of view; we know FPU is a bottleneck, we know that 2X (possibly more with NEON) is possible with the hardware FPU support, but it seems upstream isn't interested in pursuing this route (again) as they have already been down this path once before and decided it wasn't worth maintaining. From looking through the patches to remove support, it seems native FPU support brought a bunch of complications outside of the source/header you dropped in.

I did mention you have experienced around a 2X performance increase with the native path, but certainly the IRC users at the time didn't bat an eyelid about this. I must say it seems a little odd to me, most software for a long time now has been FPU heavy, it feels like keeping that code path fast would be a reasonable priority, but I guess instead they want the easier maintenance life and just let computers get faster to account for the dropped performance.

 

[ekianjo]

Its time to fork the project.

 

[sebt3]

Its time to fork the project.

Not a fork but a merge, a merge of wine and qemu This project might need a new name, though

 

[ingoreis]

New Name like:

PanWineX86 ?

Or

Qine86 for Pandora ?

Hmm near: PQinex86?

 

[Rockthesmurf]

I would imagine it is a case of priorities for lunixbochs, the sound and graphics native support being high up there for big wins that work very generically. The initial native FPU test is promising from a performance perspective, perhaps once the graphics and sound is in and working (yes there is confidence lunixbochs will nail this) other optimizations can be considered. I believe lunixbochs has already mentioned in this thread he isn't so keen on spending much more time looking at the native FPU support:

This shows us we can potentially get a 2x improvement on FPU performance by using native floating point. Probably more if we put NEON behind the SSE core. I'm probably not going to invest much more time into it however.

But as things become more stable maybe more contributors will get involved. One problem is I can't help but feel this is some pretty complex stuff which only a few developers on here would have the skill and/or time required to help. There maybe potential to have a hacked version of native FPU support where only certain functions are implemented, ones that (from testing) we know give reasonable performance boosts without breaking anything. One would imagine there will be no perfect solution; some things will work fine with certain native FPU functions, whilst other things will crash. I can see why the QEMU mainline dropped support for it, more trouble than it is worth from a lot of peoples point of view (just not from people on this forum who want to be able to play higher specification games on their Pandora!).