Ask other emulator groups to help out
#31
(02-26-2015, 11:53 PM)Blyss Sarania Wrote: The more you clamp, the slower it is. Also, even with the highest settings, it's not not the same way the PS2 handles it(which is again impossible without a complete software representation of the FPU) but it is close enough that 90% of games are happy.

I think that software FPU is a good idea once we have hardware that can do it at good speed.
When that article was written a C2D could be pushed to 4ghz, so I highly doubt a full software FPU is going to be feasible at the moment.
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply

Sponsored links

#32
Actually I would guess that a software FPU should either handle everything in atomic instructions or one needs to lock/mutex everything (which takes additional time) to avoid multiple access issues in hyperthread applications (race conditions)
Reply
#33
Now this is some interesting stuff!

Dolphin had a Software Floating Point branch for interpreter as well. But a lot of the common cases (that affected games, they use a lot, and break things) were implemented in the JIT for instructions. Now, I'm going a little bit blind, but why isn't this possible in PCSX2? To figure out ways to implement a lot of the floating point rounding correctly without huge slowdowns. Will it be slower than arbitrarily choosing a rounding mode? For Dolphin, it actually wasn't because we fell back to interpreter on a lot of the instructions that needed fixing. I don't know if that's the case for PCSX2 at all.
Reply
#34
(02-27-2015, 12:15 AM)willkuer Wrote: Actually I would guess that a software FPU should either handle everything in atomic instructions or one needs to lock/mutex everything (which takes additional time) to avoid multiple access issues in hyperthread applications (race conditions)

Huh what?!? aren't you a lil overcomplicating it? the fpu is only on the EE. needs one thread. ofc there could perhaps be something to make it faster being all case sensitive but threading imo adds to much overhead. you really wanna shove floating point numbers between threads/cores and sync the instruction execution? i'd say NOPE.
Reply
#35
Maybe you are right. I haven't considered that the EE is single threaded... But how is inter-component communication realized? How does the EE communicate with the VU? Probably in atomic instructions?

I actually have almost no idea about emulation as well as low level hardware stuff.
Reply
#36
Regardless of speed, just having a SoftFP core would be a huge boon. You'd get to see what issues are caused by CPU bugs, including tons you may not even realize. Then, based on SoftFP, you could always make a balanced/faster version in areas that really matter just like Dolphin did. This would result in more knowledge of what was going wrong at the very least.
Reply
#37
I agree it would be a good thing to have. But also, our current method was written by some of the very knowledgeable(and no longer with us) guys. I only know what I've learned from them. I say with a decent amount of confidence that our current method is likely the best short of a full software FPU, if there was a better way they woulda done it. But I do agree it could definitely assist in debugging.

My personal opinion is that the best approach right now is better usage of our gameindex.dbf and auto game fixes - it has the capability(and for some games, does) apply the proper rounding/clamping mode which that game needs. I think it should be expanded to include as many known cases as possible(something I've been working on making happen). Auto game fixes are transparent to the user, so they wouldn't have to fiddle with anything.

Ultimately of course we want better accuracy, but my understand is that it's just not a possible thing to do efficiently right now. The auto game fixes, used properly and efficiently, could provide a very nice stop gap until it is possible.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#38
(02-27-2015, 01:08 AM)JMC47 Wrote: Regardless of speed, just having a SoftFP core would be a huge boon. You'd get to see what issues are caused by CPU bugs, including tons you may not even realize. Then, based on SoftFP, you could always make a balanced/faster version in areas that really matter just like Dolphin did. This would result in more knowledge of what was going wrong at the very least.

I'm actually wondering what that would mean. Would it be something that could be added to both the fpu and vu recs? Or would it be different for each?
Reply
#39
I'm guessing both. The goal of a SoftFP branch/core/option would be to do everything as accurately as possible. Then you can find what the important pieces are and try to implement them as fast as possible, while leaving out the things that seem to have no effect.
Reply
#40
(02-27-2015, 01:45 AM)JMC47 Wrote: I'm guessing both. The goal of a SoftFP branch/core/option would be to do everything as accurately as possible. Then you can find what the important pieces are and try to implement them as fast as possible, while leaving out the things that seem to have no effect.

Yeah, I totally get that. I'm just wondering how much work this would be. Would it require new mips and vu recs? Would it be something you could add into what we currently have? If so, would there be differences between fpu and vu implementations?

Just curious.
Reply




Users browsing this thread: 1 Guest(s)