Dolphin, the GameCube and Wii emulator - Forums

Yeah I see, in regard to the stable releases Dolphin 5.0 stable was effectively the first one which required OpenGL 3.x and was 64bit only.

Whatever, in the meantime I have opened the first Mesa issue concerning the final DX9 build 4.0-154 in conjunction with the "crocus" driver (for older Intel hardware) and the alternative D3D9 API Gallium Nine:

crocus/Sandy Bridge: Partial black rendering in the game "Mario Kart: Double Dash!!" with Gallium Nine

So as said, the final DX9 dolphin build 4.0-154 can be used as a nice little testing tool to uncover D3D9 flaws in the Mesa drivers, Mesa itself or even Gallium Nine.

Furthermore I have found another milestone build, dolphin 5.0-8277 which was the last one which supported the wxWidgets UI. (DolphinWx.exe runs somehow better under Wine because it doesn't spam me at the CLI with countless "stub" and "semi-stub" hints like the Qt variant).

So my current dolphin milestone list is:

• final Qt5 milestone build is 5.0-16391
• final wxWidgets milestone build dolphin 5.0-8277
• final OGL2 milestone build is 4.0-9507 on Windows and 4.0-9508 on MacOS and Linux
• final D3D9 milestone build is 4.0-154
  

And by the way @MayImilae, yours article "Hacked Up: The Vertex Streaming Hack" needs a further little update. In Mesa, the ARB_buffer_storage OpenGL extension is as of 2022 available down to OpenGL 2.1 hardware. So this is definitely not an OpenGL4-only feature. I can confirm this for the r300 Mesa driver and my RV530 aka Radeon X1600 GPU were that extension is exposed. I was really surprised about that! And this is also true for the crocus driver on older Intel hardware like my Intel HD 2000 aka "Sandy Bridge" iGPU (which is OpenGL3 hardware). Interestingly it looks that Mesa even exposes the AMD_pinned_memory extension on any OGL3 compliant hardware while it is missing on OGL2 based one like my Radeon X1600 GPU. Because of this I would say that AMD_pinned_memory is in the end more demanding than the ARB_buffer_storage extension otherwise it we would be also available one on lower class hardware.

Unfortunately this might be at the moment not true for the nouveau Mesa driver which still lacks several capabilities because of the misguided policy of Nvidia. But it looks that also here the time is changing...

The next testing topic will be the behavior of the "GPU Texture Decoding" feature under Wine. That one seems broken, I get at the CLI a lot of "radeon: The kernel rejected CS, see dmesg for more information (-22)." and in dmesg "radeon 0000:01:00.0: evergreen_cs_track_check:980 mask 0x000000FF | 0x000000FF no cb for 1" plus "radeon 0000:01:00.0: evergreen_packet3_check:1908 invalid cmd stream" hints.

(12-08-2022, 03:33 AM)lorn10 Wrote: [ -> ][*]final OGL2 milestone build is 4.0-9507 on Windows and 4.0-9508 on MacOS and Linux

Wrong version again

Also the final build for D3D9 is 4.0-146. There are no revisions between 4.0-146 and 4.0-155. Git things.

Quote:In Mesa, the ARB_buffer_storage OpenGL extension is as of 2022 available down to OpenGL 2.1 hardware.

I'll need to look into that. EDIT: I've been told that this is true, but it is violating spec. But there are are no known issues so it's apparently fine? However, buffer storage being available on OpenGL 2 hardware is bit of Mesa special sauce and is not true anywhere else.

Sorry for the mistake, it really looks that I have lost the overview about the whole versioning. And the worst is that I can't edit my old posts and correct the information. Dear admins, this feature should be really added...

@MayImilae
Okay, here we have the "final" DX9 build at the dolphin website, it is written also in the title and description, and so far this is 4.0-154 which should be newer than 4.0-146:
https://en.dolphin-emu.org/download/dev/5d7d8be58e1a71b3fcbb2ed3be78d6a014d4c111/

So my milestone list will look as follow:

• final Qt5 milestone build is 5.0-16391
• final wxWidgets milestone build dolphin 5.0-8277
• final 32bit milestone build is 4.0-1609
• final D3D9 milestone build is 4.0-154
• final OGL2 milestone build is 4.0-26
  

I agree, the Mesa devs are quite "unorthodox" regarding the exposing of OpenGL extensions. If the hardware can support it they are usually exposing an extension. Even if that extension is much much newer than the original hardware. I think this is especially interesting regarding the mobile sector where the proprietary GPU drivers are not so good (which is meant as an understatement). This is even more true for older SoC hardware. In that aspect it would be really really interesting to look once how the last 32bit dolphin ARM builds would perform with Mesa drivers on older ARM stuff. For example, as of 2022 the Freedreno drivers seems to be great for ancient generations like Adreno 200/300/400/500. That driver even exposes an enhanced OpenGL ES 2.0 / 3.0 API as well as a lot of the standard OpenGL API.

Finally, we have a new Mesa bug report about the "DX9 testing tool" dolphin 4.0-154. This time it targets a minor bug in the r600 driver and Gallium Nine:

r600/TURKS: FPS information is missing in the game "Mario Kart: Double Dash!!" with Gallium Nine

And by the way, I can confirm for the r600 and radeonsi Mesa drivers that the "dual source blending" feature is working perfectly well also for the DX9 renderer in conjunction with Gallium Nine. So it looks that this works better under Linux than it ever did on Windows. Finally, the "fastest" renderer seems to be also under Linux the old DX9 one (with Gallium Nine and not WineD3D) but the OGL3 renderer is not far behind. That's mainly because the Mesa OGL drivers are so much better than the Windows ones (at least for AMD and Intel hardware). The Mesa drivers makes it possible that I can even play "Mario Kart: Double Dash!!" at my old low-end Intel HD 2000 iGPU which would be not possible on Windows because the old Intel drivers only expose OpenGL 3.1. That limitation for example even prevents the usage of the PSX 1 emulator PCSX-Redux.

Quote:Okay, here we have the "final" DX9 build at the dolphin website, it is written also in the title and description, and so far this is 4.0-154 which should be newer than 4.0-146:
https://en.dolphin-emu.org/download/dev/5d7d8be58e1a71b3fcbb2ed3be78d6a014d4c111/

That's in a branch, not master. Technically a fork as it does not reconnect to master, but not formally forked as it is just in a branch (hence being hosted on our site). Git things. Also it was made over a year after D3D9 was removed from Dolphin and after we had already moved on. 4.0-595 from Dolphin master is the same age as your "4.0-154". The title "DX9-Final" is the name of the branch, btw. On our site, Dev builds do not have titles over them.

The final D3D9 build in Dolphin is 4.0-146.

Quote:Finally, the "fastest" renderer seems to be also under Linux the old DX9 one (with Gallium Nine and not WineD3D) but the OGL3 renderer is not far behind.

I will remind you that Dolphin is WAY faster today than it was in the D3D9 era, as Dolphin today can use modern features to greatly reduce the amount of translation nonsense it has to perform. This gives modern Dolphin both higher accuracy and more speed. You'd get far superior performance with a modern build, even on min-spec OpenGL 3 hardware. You are getting better performance due to your own constraints you are placing on Dolphin, and potential just from how terrible that ancient Intel iGPU is. Seriously pre HD4000 Intel iGPUs are awful and caused us no shortage of headache back in the day.

Looking at the spec for ARB_buffer_storage, its not clear that implementing it on GL2 hardware would be against the spec. It's written against the 4.3 spec (OpenGL extensions are basically like a patch file you could apply to the text of the OpenGL specification), but that doesn't mean it can only work with OpenGL 4.3. As long as the 'patch' applies, everything's fine, so that could mean that the extension doesn't rely on any GL4 concepts and is just as applicable to GL2, or could mean that it does rely on some GL3/GL4 stuff, but Mesa have made that available via extensions, too.

Out of spec, then.

And now it's time for a year 2023 addition to this topic.
After a longer testing round (which included the collection of 30 Shines in Super Mario Sunshine) and in conjunction with the latest under Wine working Dolphin-5.0-16391 build I can confirm that the OGL3 path is definitely faster in comparison with the old DX9 mode.  

The most interesting thing is that this is true even for an old Intel HD 2000 iGPU which is only OpenGL 3.3 compliant. This Gen6 Intel graphics was the first "somehow more performant" iGPU but it was still not made for gaming. And now I can really play Super Mario Sunshine at a reasonable FPS rate also on that old GPU. Awesome! Maybe it should be added that this is probably only possible because of the superb quality of the present-day Mesa drivers.

So @MayImilae was / is really right. Newer Dolphin releases outperform the old DX9 based build also on vintage hardware, - if the GPU driver quality is good. On the same time newer builds are much more accurate in regard to the emulation. So my result should definitely refute the claim / myth that only the Vulkan path is faster then the former DX9 one. At least for Linux and up-to-date Mesa drivers this is not true or no longer true, - even under Wine.

If someone is interested in reproducing, I can give some examples were the DX9 path is slowing down noticeable in comparison to the OGL3 one.

• In the first level "Bianco Hills" and Episode 4 "Red Coins of Windmill Village", there are those "Wind Spirits" enemies which are attacking Mario. If that happens, the DX9 renderer goes significantly down, at the Intel iGPU it becomes almost unplayable. That also occurs at my Radeon HD 6770M GPU but the slowdown is not that huge.
• When walking on the "ropes" and viewing into the wider landscape then there are occurring sometimes also some slowdowns with the DX9 path. However, that may depend also from the effective position aka the "view-point".
• When splashing around water like a maniac then there are always slowdowns with the DX9 path. The OGL3 renderer can handle this much better, there exist at the Intel iGPU and OGL3 only minor speed regressions which also doesn't happens always.
  

The only regression which is present with OGL3 at the Intel iGPU but not with the DX9 path is a trivial slowdown in the audio / video when the game level map is displayed / loaded through the "Z" button.

At this point I want to say a BIG thanks to all involved dolphin devs for their great work in this project!

Okay, my final milestone list looks as follow:

• final Qt5 milestone build is 5.0-16391
• final wxWidgets milestone build dolphin 5.0-8277
• final 32bit milestone build is 4.0-1609
• final D3D9 milestone build is 4.0-146 (while build 4.0-154 is newer but forked from 4.0-595)
• final OGL2 milestone build is 4.0-26
  

Note, Qt5 build 5.0-16391 requires under Wine a modification of the "Dolphin.ini" file. The value "RecursiveISOPaths = False" must be added under the [General] section right above "NANDRootPath" and "RecursiveGCMPaths = False" above "GCMPath0".

And regarding the exposing of newer OpenGL features on older hardware like Mesa is doing it. Maybe the whole matter is not that strict and more "fluent". I am thinking specifically of OpenGL ES 2.0 at this point. In Mesa, there are a lot of optional extensions included at most drivers which became "core" in OpenGL ES 3.0. So if the hardware is capable, then it may be possible to run OpenGL ES 3.0 applications via those optional extensions also at older hardware as long the GLSL ES version remains compliant. Yes, this will not work with Dolphin but most likely with PCSX-Redux, a PSX1 emulator. It requires OpenGL 3.1 but so far I know no geometry shaders or any "higher functionality" is used. So therefore, when looking at OpenGL ES it should be theoretically possible to make an OpenGL ES 3.0 renderer which runs also at ES 2.0 hardware with additional extensions. That doesn't mean that every ES2 hardware will become compliant, but some should be. In this example I mean particular Shader Model 3.0 based hardware like the ATI R500 series was. As long as the necessary ES extensions are available it could run ES 3.0 applications. At the same time older ES2 hardware like the ATI R400 and R300 series will remain incompatible because the limited hardware doesn't support the needed optional ES2 extensions.

I made a thing - https://wiki.dolphin-emu.org/index.php?title=Notable_Removed_Features_and_Support

(01-14-2023, 03:38 PM)MayImilae Wrote: [ -> ]I made a thing - https://wiki.dolphin-emu.org/index.php?title=Notable_Removed_Features_and_Support

Awesome, - something like that was definitively missing!  

In some regard it was really time to tell more about dolphins amazing history and the notable changes during the releases. Not every project has such a history....

Now we have some sort of dolphin "milestone" build chronology, - great and thanks for that!