Dolphin, the GameCube and Wii emulator - Forums

(01-15-2023, 02:47 PM)MayImilae Wrote: [ -> ]I don't have the ability to test ARMv7 - I have a bazillion ARM devices but they are ALL ARMv8. If you can find the final working ARMv7 build I'll gladly update the chart. But you are right about it being broken before it was removed so I'll update the chart by saying the final version is unknown. EDIT: Oh, I DO have an ARMv7 device. I have an original Nvidia Shield Portable, which is powered by the ARMv7 equipped Tegra 4. ...you should probably find out yourself though, I am chronically distracted after all and from the looks of things that isn't going to change until maybe 2024. I probably will never get around to it.

OK, it seems like the the last working build is 4.0-4943. The first broken is 4.0-4963. This is a little after the claimed November breaking point, and IDK what the deal with android 5.0 is. (I'm using an android 13 custom rom) 

Fastmem works inconsistently for some reason. I haven't quite narrowed down why the game sometimes doesn't start. Maybe something with changing settings?

Test video: https://youtu.be/7arKBU_m0SY 

Hmm, 4.0-4963 breaking it doesn't make sense. It's an MMU change that only affects x86. So the failure might be a builder update.

(01-17-2023, 01:46 AM)MayImilae Wrote: [ -> ]Hmm, 4.0-4963 breaking it doesn't make sense. It's an MMU change that only affects x86. So the failure might be a builder update.

I didn't read through it in great detail, but it does make changes to platform-independent code too. Maybe something was changed that would have required a matching change in the ARMv7 JIT?

Hmm, when I first looked at the diff I just assumed it was something in JitCommon, but I guess arm has a seperate common. Although this pr makes me think there might be arm stuff in that common anyway? Does arm really depend on nothing that was changed?

I found someone else with the same bisect https://forums.dolphin-emu.org/Thread-latest-build-compatibility?pid=352791#pid352791

Although looking into it more, this might be the android 5.0 issue? There are arm7 specific changes after this that are presumably tested. Apparently the 5.0+ problem is a memory mapping problem?

"It doesn't work around the memmap error."

"ARMv7 devices have crashed on launch for about 2,000 commits now, when running Android 5.0 or above. The app fails to map enough memory to start emulation, and crashes."

I don't remember if the Nvidia Shield Portable that I have is running Android 4.4 or 5. It will be quite a while until I'm able to test it though, hopefully someone else can test it.

(12-01-2022, 01:04 AM)lorn10 Wrote: [ -> ]Hi all, here follows now a suggestion for improvement.

Maybe it would make sense to add two additional download links at the first page in the download section regarding the "iconic" build 4.0-154 and the classic 4.0-9507.

While dolphin 4.0-154 is the last version with D3D9 support, build 4.0-9507 was the final one with OpenGL 2.0 (which is true for Windows). MacOS and Linux had 4.0-9508 as the last OGL2 release. In some regard those are all milestone releases and they therefore deserve a special place at the download page.

Some will wonder why this is relevant when all people uses Windows 10 or Windows 11. Well, some are still using older Windows versions and others are using Wine under Linux and those ancient builds are the perfect Wine testing candidates. Yes, there exist also native dolphin builds for MacOS and Linux but those two dolphin releases mentioned here are perfectly well suited to test the Windows application behavior in later Wine releases. Furthermore they can also be used to test the corresponding native Video API quality in Wine.

As a result it can be said that dolphins OpenGL performance is on Linux far better then under Windows simply because of the excellent driver quality of the Mesa drivers. This was tested with Mesa 23.0.0-devel (git-3507cdc 2022-11-29 jammy-oibaf-ppa). So it is not true that D3D is generally better than OpenGL. This depends primary onto the underlying drivers. For most GPU producers the OpenGL situation under Windows had not any high priority and that's the main reason why it is performing often badly, especially for AMD. But as said, this is true only for Windows, on Linux the OpenGL situation is completely different, it is almost perfect.

I can confirm that build 4.0-9507 works superb under Kubuntu 22.04 LTS and Wine devel 7.22. It is just recommended to copy over the original MS msvcp140.dll file (into the folder of dolphin.exe) and override the corresponding dll preference to "native" in winecfg. This will bring away some returning wine "stub" and "semi-stub" warnings at the CLI.

Also dolphin 4.0-154 runs nice under Wine devel 7.22. It is the perfect candidate to test the native Direct3D 9 API in Linux. Yes, there really exist such a thing, its called Gallium Nine. And also here, the performance of the native D3D9 renderer is impressive. I was even able to run Mario Kart - Double Dash!! and Super Mario Sunshine with dual source blending enabled, so I have added "ForceDualSourceBlend = True" in gfx_dx9.ini. If this really activates that function also in the D3D9 renderer (like in OpenGL) then that would mean that this feature works better in the alternative Linux D3D9 API then in the original MS D3D9 implementation. The only smaller issue is that dolphin 4.0-154 outputs at the CLI a massive amount of "0138:fixme:msvcrt:Context_Yield ()" hints which cannot be turned off. But as far I can say they don't affect the operation.

In contrast, all current Qt6 based dolphin builds seems to be fundamentally broken under Wine. The latest working ones are all Qt5 based. For example, the only issue in Dolphin 5.0-16391 is that the graphics card information in Wine is not properly adopted which results in an empty "graphics card" box. This is not a problem because the "backend" can be set to OpenGL. Wine will ignore the missing GPU information and still uses the accelerated GPU OpenGL path. Besides that, dolphin 5.0-16391 runs fine with OpenGL 3.0 although the sound behavior seems not as good as in 4.0-9507. Furthermore there are at the CLI a lot of returning "014c:fixme:bthpropscpl:BluetoothFindFirstRadio (000000000602FAF8 000000000602FB00): stub!" hints which unfortunately cannot be prevented. But also here, this doesn't seems to affect the overall operation.

Finally, the situation of dolphin in conjunction with Wine can be regarded as very good. I really didn't expect that.

Ever heard of Lutris?