Dolphin, the GameCube and Wii emulator - Forums

Hello.

I find your project amazing in many levels.

Congratulations for the OpenGL article, I really hope AMD and Intel wake up and someday catch Nvidia in FOSS drivers. You all aren't only able to know graphics API , but able to test them to see how good or bad they are too

Dolphin shows how more complex systems can be emulated and the challanges of making it happen. I also consider it to be a great project for people that wants to be good at GPU programming too.


Too much sucking up! Now here's the questions!

- Do you think Vulkan could evolve to become something better than the best OpenGL implementation?

- If that's possible: What would be needed to make projects like Dolphin have as more advantages as possible by a new iteration of this new graphics API?

- Do you think Vulkan is a step in the right direction?

- What do you think are the biggest limitations and issues of graphics APIs? ç

- What do you think it would be the best approach to evolve?

- Why is NVIDIA able to provide good graphics drivers and the competition releases such broken drivers? Do they lack the manpower and talent to make it happen? Are there hopes this would change?

- Why are OpenGL/Vulkan implementations proprietary most of the time and they don't care about the MESA/Gallium3D approach? Do you think companies like NVIDIA and others hide their "secret" sauce in the drivers and not going to make better drivers until they move most of their secrets to binary blobs aka firmwares? What are they so stubborn to hide?


Would you please consider about making an article about Vulkan? Of course take your time. It would be amazing if being a bit as amazing as your OpenGL article!


Kind regards.

- Do you think Vulkan could evolve to become something better than the best OpenGL implementation?
They have different use cases. Vulkan tries to match the hardware as closely as possible, OpenGL tries to provide an API for GFX development. So very often, OpenGL just match better. But for eg game engines, Vulkan is by far the better choise. But Vulkan requires more knowledge about GPU internals, and much more code to write. So the common way will likely be to only use Vulkan if you need to...

- If that's possible: What would be needed to make projects like Dolphin have as more advantages as possible by a new iteration of this new graphics API?
Writing a new video backend. There was a pull request some weeks ago for the new D3D12 video backend, so just the same again for Vulkan.

- Do you think Vulkan is a step in the right direction?
I think it will help a bit for dolphin. But the biggest improvements are already done within the OGL backend. AZDO with persistent mapped buffers are a good example. Another good improvement may be the PipelineObject cache. Right now, each GL driver should cache them already. With Vulkan, we have to do this. As we're on a higher level, this cache may be a bit faster. Especially if it's done *very* bad in the driver (looking at those mobile vendors...).

In general, I fear Vulkan might not live for the next 20 years. It's on a lower level, so the API needs to be redesigned earlyer... Still fine, but everyone should check their requirements...

- What do you think are the biggest limitations and issues of graphics APIs?
At which level the developer wants to program. Writing shaders is simple, keeping care about memory management isn't. There is a point why this has such a high overhead within GL drivers. Lower level allows you to optimize everything, but it requires you to take care about everything. For me, it sounds like Vulkan and D3D12 matches the hardware quite well. But most programmers don't want to programm for the hardware directly.

For dolphin, there is a huge bottleneck which Vulkan tries to fix for game engines. The biggest performance gain of Vulkan is because of cached command buffers. Generating command buffers needs lots of hardware dependent state checks and validation. On GL, there are no command buffers (there were, called display list. They matched the hardware by time, but some years later, they were only emulated within the driver). Everything is queued on creating directly. Vulkan allows to cache and reuse those command buffers, and to generate them threaded. The creation of command buffers is also high in dolphin, *but* dolphin can't reuse command buffers. The emulated GPU doesn't match to the current design of command buffers, so we have to generate a stream of commands and to use them once. So the main improvement of Vulkan and D3D12 doesn'T apply for emulation :/

I fear this might hurt us very badly. Let's hope all of those vendors still tries to be as fast as possible on command buffer generation. This *was* a bottleneck in GL, but on Vulkan, this is only a bottleneck for badly written games, like every emulator....

- What do you think it would be the best approach to evolve?
Flexibility, low overhead, stable API. I guess we have to choose....

- Why is NVIDIA able to provide good graphics drivers and the competition releases such broken drivers? Do they lack the manpower and talent to make it happen? Are there hopes this would change?
As far as I know, AMD is more comform with the GL specs as NVidia. But most GFX devs just develop with NVidia, and if other vendors have a different behavior, they are called broken.
But I think that's not the point here. It's really hard to write a comform GL driver. But it's by far harder to write a fast GL driver. GL usually doesn't specify what the hardware shall do, neither how fast (or slow) some calls might be. It's just defining the resulting behavior. There are often different ways to get a result, and by far more ways for the hardware to do so. There are usually no meanful hints how the driver shall do it, so they have to guess. It seems like NVidia spend more time to guess what the game wants to do.
The other point is about GPU utilization vs CPU overhead. Most vendors care most about GPU utilization. So a game should still run fine on very high resolution. Driver overhead is more about geting a very shitty game (like emulators...) still running fast while the GPU is mostly idle. Only some strange application will profit if the vendor optimize here, so it seems like mostly NVidia tries to do so...

- Why are OpenGL/Vulkan implementations proprietary most of the time and they don't care about the MESA/Gallium3D approach? Do you think companies like NVIDIA and others hide their "secret" sauce in the drivers and not going to make better drivers until they move most of their secrets to binary blobs aka firmwares? What are they so stubborn to hide?
Oh, please ask me technical questions
But both intel and amd mesa drivers are written by paid developers. NVidia is the one trying to do everything to get their blob working as good as possible.


- Would you please consider about making an article about Vulkan? Of course take your time. It would be amazing if being a bit as amazing as your OpenGL article!
I'm pretty sure there will be one

Vulkan may not benefit Dolphin that much if you have an NVIDIA GPU and use the super fast OpenGL backend with AZDO, but you're forgetting something:

AMD's OpenGL driver is still a piece of crap. It runs slow as molasses, the CPU overhead at lower resolutions is massive, it's extremely slow / inefficient at higher resolutions (>4xIR), gobbles up a huge amount of VRAM (compared to D3D), lacks some OpenGL 4.5 extensions and all of the ARB 2015 (GL 4.6) extensions that the NVIDIA driver has.

The Vulkan backend will help AMD users tremendously. Especially users that have both an AMD GPU *and* CPU. They'll get the biggest speed boost. The Vulkan backend might be even faster than the Direct3D 11 backend and comparable to NVIDIA's super-fast OpenGL driver (that already performs faster than AMD's Direct3D 11 driver).

And finally, Vulkan still works on Windows 8.1 , Windows 7 and Linux, so most users will benefit from the improved performance without being forced to "upgrade" to a buggy / alpha-quality / incomplete OS (Windows 10) just to try the [awesome] Direct3D 12 backend.

Someone should hack the backdoor of their own Windows 10 computer and crack the code for DX 12 to make it available on Windows 7.

The friendly dev here already explained how Vulkan apparently can't work,but hopefully someone can research for other ways to do things to see if they can figure out how to make Dolphin run in a completely different way that is more compatible with using Vulkan.
Despite being of similar architecture of an actual PC,what is RPCS3 doing with Vulkan?

I thought of what might need to be done before Vulkan could be used for it,you would have to port Vulkan to the Gamecube's and Wii's architecture and code it for the processors before it could be compatible for using with Dolphin and then backport the result to Android for it and PC for anyone that wants it on their computer.
That sounds like a really daunting task alone,but also backporting it too making it even more daunting.

(02-27-2016, 04:52 AM)retroben Wrote: [ -> ]Someone should hack the backdoor of their own Windows 10 computer and crack the code for DX 12 to make it available on Windows 7.

That's... not really how it works.

(02-27-2016, 04:52 AM)retroben Wrote: [ -> ]The friendly dev here already explained how Vulkan apparently can't work

No, Vulkan can work in Dolphin if someone writes a video backend for it.

(02-27-2016, 04:52 AM)retroben Wrote: [ -> ]I thought of what might need to be done before Vulkan could be used for it,you would have to port Vulkan to the Gamecube's and Wii's architecture and code it for the processors before it could be compatible for using with Dolphin and then backport the result to Android for it and PC for anyone that wants it on their computer.
That sounds like a really daunting task alone,but also backporting it too making it even more daunting.

That's not how it works at all.

I must of got confused about that talk of game engines and JAVA with the gnomes engine demo benchmark and the VRAM mentioning,got my brain scrambled,it had the dashes on the left for quotes.
I saw a video of straight up proof in how much better Vulkan handled it compared to OpenGL ES 3.0 on Android.
(though Dolphin requries 3.1,this still is a valid example with Vulkan's support of OpenGL 4.5 features)

Also,I just found out (I are idiot,it was PS4 with PC architecture) that PS3 is also PowerPC based.
The problem is likely to be what Gamecube and Wii each have for the GPU,as PS3 is Nvidia.
Both Wii and GC *looks it up to make sure* use Hollywood and Flipper respectively with ATI,and that is also a GPU brand used in a PC via their Radeon GPU for example.
But being as it is with Dolphin as an emulator for those processors might make it less difficult to those that understand the system hardware being emulated.

Starting to look extra plausible now for whomever decides to tackle it if they do.

It would take more work,but extra stuff that would be done on Android for improved performance with Vulkan is more support by using quad core multi-threading after updating the JitARM64 to support an option to use four cores at a time instead of just dual core,gaining the quad core CPU speed boost.
That is the biggest reason for Vulkan to be at least considered,as it can take better advantage of CPU usage with lower overhead.
An earlier discussion about quad core multi-threading stated that it wouldn't improve performance because the 3rd and 4th CPU would not be used enough to make any difference,but that was likely due to OpenGL and possibly DX11 limits.
Vulkan is capable of spreading the work accross all four CPU cores evenly on heavy load,sustaining higher fps in more intense moments,the perk of direct GPU control likely assists in this.

I can't even understand what you're trying to say.

(02-27-2016, 05:53 AM)retroben Wrote: [ -> ]An earlier discussion about quad core multi-threading stated that it wouldn't improve performance because the 3rd and 4th CPU would not be used enough to make any difference,but that was likely due to OpenGL and possibly DX11 limits.

That was not because of OpenGL and Direct3D 11 limits. Vulkan won't make Dolphin use four cores fully.

I see,looking at older threads about quad core would have to split CPU and GPU which would mess it up completely with desyncs,so thatt can't be done.
At least OpenGL ES does not support multi-threading,leading to limitations when Vulkan does support it.
But I have another idea for Vulkan usage,what if the other 2 cores used threads for the individual uber shaders being planned and maybe also DSP for faster lle audio even though that doesn't relate to graphics?
(the normal shader would still not use multi-threading to show the already generated ones)
Could that be done and in a way that dynamically takes care of the shader stuttering while giving Dolphin more room for performance with extra free CPU usage space for the emulated gpu and cpu threads?

Graphics already glitch before being visible when shader generation takes place anyway,on Brawl and Wind Waker.
The first bom plant I used started with missing explosion bits for a split second on the 2nd PR of the performance build.

Currently,it seems Ubershaders by phire are quite a long ways into development,Wind Waker is shown as nearly perfect with only the fire effects not working right from indirect textures having issues.
Might be more things fixed internally since then but with no new progress details or screenshots beyond that point.

(02-27-2016, 06:58 AM)retroben Wrote: [ -> ]But I have another idea for Vulkan usage,what if the other 2 cores used threads for the individual uber shaders being planned

I think the plan is something like that. Compiling specialized shaders on a separate thread will help avoid shader compilation slowdown, but it won't increase performance in other cases. This isn't exclusive for Vulkan, though.

(02-27-2016, 06:58 AM)retroben Wrote: [ -> ]and maybe also DSP for faster lle audio even though that doesn't relate to graphics?

Dolphin already uses a separate core for LLE audio when possible.