Release WINE

[Askarus]

If everyone on here would grab 5$ and sens it to lunixbochs he might change his mind and work on the FPU.

 

[sebt3]

If everyone on here would grab 5$ and sens it to lunixbochs he might change his mind and work on the FPU.

doubtfull, he doesnt sound motivated by money. I can be wrong on that though

 

[rohezal]

steven just fo my couristity where is the difference betwen the arm floats and the x86 floats? little vs big endian? different size of the mantisse / exponent? different operations for floats?

what kind of operations are used how often? mad, mul, div, add, sub are supported by arm, right? if they are handled nativly, and more exotic functions stay software only, it would still by a big speed boost.

 

[WizardStan]

New Name like:

PanWineX86 ?

Or

Qine86 for Pandora ?

Hmm near: PQinex86?

QWINE

 

[Stainy]

Pine.


Sent from my Amiga using the cli.

 

[notaz]

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

It's a real shame they went that way, qemu was initially written with performance in mind, here is how it used to describe itself:

QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed.

And now it's more like "qemu is processor emulator intended to be easy to maintain for the maintainers."

 

[Rockthesmurf]

steven just fo my couristity where is the difference betwen the arm floats and the x86 floats? little vs big endian? different size of the mantisse / exponent? different operations for floats?

what kind of operations are used how often? mad, mul, div, add, sub are supported by arm, right? if they are handled nativly, and more exotic functions stay software only, it would still by a big speed boost.

My understanding, which is extremely limited, and only based on doing a little bit of reading after going through this thread is:

• QEMU translates incoming code from the destination platform (X86 in our case) into an intermediate language
• This intermediate language is then compiled/assembled into something for our target CPU (which is ARM)
• During the translation, all floating point operations go through the soft float implementation, which ultimately means all floating point operations are actually performed as integer operations

The reason for doing all floating point calculation as integer calculations is to ensure you get exactly the same results, two different CPUs can calculate different results otherwise (it appears the error cases are the most common to go wrong, i.e. when invalid numbers 'NaN' are passed in) but presumably other cases can also go wrong depending on the FPUs implementation. There are also limits as to what functionality the FPU supports (some architectures will have instructions not supported by other architectures). As an example of floating problems, recently I had something in my code which did something like '32 * 0.375' which is 12, only the FPU I was doing it on decided the result was actually 11.9999999. My code was casting this to an integer, which means the fractional part gets discarded, so on all other platforms it remained at 12, but on this one platform it got truncated to 11. This then caused major breakages (as you can imagine). So having FPU operations performed exactly right (down to the last bit) is the goal of QEMU, with good reason.

In terms of how do you implement floating point maths using integers, well the source code is in softfloat.c - and as you can see it is relatively complicated. The patch lunixbochs implemented was from an old version of QEMU that just performed all the FPU operations using the FPU on the Pandora. This means that 'result = 12.1 + 13.2' stays as 'result = 12.1 + 13.2', so an instruction for an instruction. If everything was this simple we could emulate a 1 GHz x86 machine with our Pandora! This obviously isn't the case but it gives you some idea. Instead, if we use the soft float implementation, a 'simple' add operations becomes tens if not hundreds of lines of C code, I don't know offhand what this compiles down to, but I should imagine at least 10's of instructions in the hot path (as in instructions that will get executed the majority of the time). So you end up with something that is 10X slower than the native version (the number 10 I am just pulling out of thin air here).

In terms of endian, right now I think we are only interested in little endian, so this probably doesn't come into play.

With regards to how often does this slow code get used, lunixbochs has indicated quite a lot, at the very least floating point operations are the biggest bottle neck at the moment (I believe that is what he said).

Finally, the question of can we implement certain functions natively, get a speed boost, and relatively few problems, I don't know the answer for sure. I hope yes, and it is certainly my suggestion of something to potentially to try. I am just aware it is a lot easier for you and I to suggest things than it is to pull ones sleeves up and help contribute to the project. Plus, I feel probably lunixbochs is already aware of most of the suggestions here.

EDIT:

@notaz it also says:

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

On the web site for QEMU, which doesn't seem true any more at least...

EDIT1:

@notaz I did also ask on IRC if there is a fork/sub-project based on QEMU that favours speed over bit accuracy, to which the answer was none they were aware of. Maybe if we do end up with something here that works well with some native FPU they may decide our changes can go upstream after all. I also asked about whether they did any benchmarks before removing, as it seems softfloat is going to degrade performance for a lot of applications, the response was simple 'bit-accuracy wins over performance'. It isn't what I'd like to see/hear but there we go.

 

[TrashyMG]

I've tried Half-Life 1 again, This time with the newer wineroot and the qemu-fpu binary lunixbochs shared.. It does seem a bit faster, but the qemu-fpu introduces odd graphical bugs, missing text in the menu fields and inverted colors on some textures. But sound wise it's smoother and it did pick up bit of a few FPS.. I'll record a video once I get a quiet space to do it.

 

[Edglex]

I had a look at the fpu and mmx code and while I'm tempted to get my hands dirty I don't really have the time, but after looking at the code I just thought I'd drop by to pass on some advice to turn off the strict overflow and strict aliasing optimisations in gcc if they aren't already, in case they are screwing things up for you. You do this by giving the -fno-strict-overflow and -fno-strict-aliasing options (or even -fwrapv and -fno-strict-aliasing) to gcc.

The reasoning is that a lot of overflow-type checks are being used in this code and a lot of aliasing is being done with casts. The purpose of the above options is to basically make your code faster by removing any code that has aliasing or overflow checks when gcc has determined that their behaviour is undefined/can't occur according to the C standard, which you frequently really really don't want gcc to do. I've lost count of the number of times I've seen fstrict-overflow remove critical (from a safety or stability perspective) overflow checks that the programmer intentionally put there, because it determines that overflow can't occur. strict-aliasing can also result in code re-ordering which could also be very bad. 

Anyway, this might not help at all but it could be worth trying as it could improve accuracy (and maybe somehow performance, though can't think exactly how) of your fpu stuff.

 

[rohezal]

A custom hack for the pandora qemu version would not be possible, right?

void processData(int opcode, float register1, float register2)
{
   if (opcode == FMUL || opcode == FADD || opcode == FSUB || opcode == FDIV)
   {
       result = hackedPath(opcode, register1, register2);
   }

   else
   {
      result = normalPath(opcode, register1, register2);
   }
}

//
float hackPath(int opcode, float register1, float register2)
{
    if(opcode == FMUL)
    {
         return(register1*register2);
    }
}

 

[lunixbochs]

If everyone on here would grab 5$ and sens it to lunixbochs he might change his mind and work on the FPU.

doubtfull, he doesnt sound motivated by money. I can be wrong on that though

Send your spare money to the preorder queue.

Donations won't give me more free time (unless they somehow manage to replace my day job) so they aren't likely to shift my priorities.

 

[ingoreis]

Have you tried a older Version of Qemu,sometimes are older Versions faster

If everyone on here would grab 5$ and sens it to lunixbochs he might change his mind and work on the FPU.

doubtfull, he doesnt sound motivated by money. I can be wrong on that though

Send your spare money to the preorder queue.

Donations won't give me more free time (unless they somehow manage to replace my day job) so they aren't likely to shift my priorities.

Oki Doki,donated 50Euros ^_^

Edit: in the Past have we best speed Results with Qemu Version 0.15.01 maybe you give it a Try

 

[Askarus]

If everyone on here would grab 5$ and sens it to lunixbochs he might change his mind and work on the FPU.

doubtfull, he doesnt sound motivated by money. I can be wrong on that though

Send your spare money to the preorder queue.

Donations won't give me more free time (unless they somehow manage to replace my day job) so they aren't likely to shift my priorities.

Dammit .

 

[lunixbochs]

Edit: in the Past have we best speed Results with Qemu Version 0.15.01 maybe you give it a Try

Unfortunately any QEMU version before 1.6 won't work very well.

 

[ingoreis]

Edit: in the Past have we best speed Results with Qemu Version 0.15.01 maybe you give it a Try

Unfortunately any QEMU version before 1.6 won't work very well.

Oh OK,but thx for Information ^_^

In the Moment try i to install your Wineroot into Bodhi Linux on Pandora,

but Xhost is there not Aviable,i will try to compile Xhost

 

[lunixbochs]

xhost just makes it easier for qemu'd WINE to connect to the X display. Might work for you without it.

 

[Solstar]

it boggles the mind that now you guys can play those hardware demanding windows games(some at.."decent" speed,according to your videos)while 3d games still struggles on DOSBOX for pandora..

 

[ingoreis]

it boggles the mind that now you guys can play those hardware demanding windows games(some at.."decent" speed,according to your videos)while 3d games still struggles on DOSBOX for pandora..

Load Linuxbochs GL Lib and install it on your Dev System...
...Compile Dosbox with the 3DFX Patch and have Fun then


Its for Dosbox possible because Linuxbochs GL Lib.


Maybe you can ask the Devs in the Dosbox Thread


But here is Qemu and Wine Thread


Little ontopic Report from me:


Bodhi Linux spill Errors out when i try to execute Qemu-I386 because some Libraries are not found and even Google dont know this Files


ELW(Dev for the Pandoraversion from Bodhi) mean that can be because his Bodhi Linux is Hardfloat created.


Under Slackware i have this Sudo Error,(Linux Swat have a Solution that i will try soon again for that error)


Under Bodhi Linux work it not too,


Under Super Zaxxon get i some Glib Errors.


Its difficult for me with your prep.sh to get it right working for me.


All my operating Systems for Trying are on SD Card,can you please make a simply install.sh for it?


Today Evening will i try more,have a fresh Slackware Stable on SD and must answer in the Sudo Solution Posts for it


I hope i get it work good this evening.

 

[Linux-SWAT]

I already explained to you why gksu (it's NOT a sudo problem) fails, and how to use the alternative method...

See the development thread.

 

[GizmoTheGreen]

this is really exciting for me, good luck with future efforts lunixbochs