Quote:Hi,
I was wondering what the reasons for the graphics cards requirements of dolphin are. It's easily understandable that the CPU requirements are a multiple of those on the original platform, because all the instructions need to be emulated. However, why are the graphics card requirements also much higher?
You just said why. Just like the cpu instructions the gpu instructions also need to be emulated.
Quote: Isn't all of the actual emulation performed on the CPU?
That depends on what you mean by that.
I think first we need to establish some basics that you may or may not already know.
PC applications that use a GPU (video games for example) are programs written in a typical programming language (C/C++/C#/java/python/whatever). Whenever the programmer needs to do something on the GPU instead of the cpu (draw a textured rectangle for example) they write a shader to do that task and have the main program call that shader whenever they need to do that task. Shaders are just programs that run on the gpu that manipulate texture and vertex data. So I might write a shader that draws a red rectangle and call it DrawRedRect. Then every time my program needs to draw a red rectangle I just call the shader DrawRedRect. So the program runs on the cpu and simply called a shader every time it needs to the GPU to do something for it. The alternative would be to not use the gpu. Instead of writing a shader for DrawRedRect I could make a function called DrawRedRect and write it using C++ code instead of a shader language. I would then call that function instead. Since that function is not a shader it would run on the cpu just like the rest of the program, which is called software rendering. Shaders are basically functions that run on the GPU, we use the terms shader to differentiate them from regular functions that run on the cpu. The whole idea behind using shaders is that the GPU can do certain things much faster than the cpu can (drawing a rectangle for example), which is why it is commonly referred to as "hardware acceleration" (as in we are using a dedicated piece of hardware, the gpu, to accelerate the task by performing it faster than the cpu could).
When the program calls a shader (which is basically just a function written in a shader language) the API (direct3d, openGL, etc.) compiles the shader into shader bytecode. Then the GPU drivers compile the shader bytecode into GPU machine code (binary instructions) which is stored in a command buffer. The GPU reads in the instructions from the command buffer and decodes them into microcode which configures the stream processors. The program itself runs on the cpu, it is impossible to write what we would typically think of as an application that runs entirely on the gpu. The program simply emits instructions (by calling shaders) to make the gpu do work whenever it needs the gpu to do something. The program running on the cpu can be thought of as a client and the gpu can be thought of as a server. Just like with a real server you need a client (a program running on the cpu) to tell the server what to do.
Dolphin is technically one program. But for the purposes of explaining this we can think of each thread as being a separate program that does something different. The cpu emulator engine (interpreter, JIT recompiler, JITIL recompiler) can be though of as a program that emulates the gecko cpu in the GC/Wii. This program does not use the gpu for anything. The video thread is like a program that emulates the flipper GPU in the GC/Wii. This program uses a framework (openGL, direct3d9, or direct3d11) to provide access to the GPUs resources (because that's the only way to access the gpus resources). We also have a software renderer that does not use the gpu at all for flipper emulation. GPUs are designed for graphics related tasks, and since that's exactly what the flipper does it makes sense to use shaders running on our gpus to speed up the emulation of a lot of stuff (as evidenced by how painfully slow the software renderer is). However the video thread is like a program that emulates the flipper gpu. As such it has lots of c++ code that runs on the cpu and lots of shaders as well to do the more visual oriented stuff (for example if we needed to change the state of a flipper register that would be done with c++ code, but if the flipper needs to filter a texture it would make sense to do that on the gpu). Remember that we are emulated the hardware, not the software. The video thread is software that mimicks the behavior of the flipper gpu, it doesn't just produce the same result as the game would on the real hardware, it does it by actually mimicking the hardware, which takes things a step further. This "program" can be thought of like a virtual flipper, and as such needs to be able to do EVERYTHING that the real flipper can do. All the way down to registers and state changes. The simple fact that dolphin has to do all of this at the software level makes it very inefficient compared to the real hardware. It's the exact same reason that gecko (the GC/Wii cpu) emulation requires a much more powerful cpu.
But there is another reason besides the usual "because it has to emulate it" reason. You see back in the "old days" (not that long ago quite frankly) shaders were fixed functions, they were not programmable like they are these days. What that means is that the gpu was designed to do certain tasks a certain way through an API, and as a person interested in using the GPU for hardware acceleration all you could do with shaders was call the shaders that had already been made for you and included the with APIs libraries. You could not make your own shaders to do whatever you wanted, you had to use the shaders that were already made for you because shaders were not programmable. Our modern gpus use programmable shaders, but the flipper is totally fixed function. We need to emulate these fixed functions and fixed shaders with programmable shaders that our developers write. So once again we are trying to do something that the flipper gpu was designed for at the hardware level using software, and software is always going to be less efficient that fixed hardware.
These frameworks that we have to use to provide hardware acceleration have a set of rules that we have to follow to use them. Although the shaders are programmable through the use of a shader language there are many restrictions put into place by both the API and the hardware. Some of these restrictions prevent dolphin from emulating certain features of the flipper (such as bounding boxes for example).
But seriously all of that can be summed with "because it's an emulator". And anyone who has ever worked on or looked at the code for an emulator before will instantly know what you mean.
Quote:The corresponding thread seems to suggest that video memory bandwidth is the relevant specification. Why is that?
.....because the gpu has its own dedicated memory, called video memory.
Pretend for a minute that you had a PC without a graphics card. Your computer performs 4 basic functions, input, output, processing, and storage. When your PC runs a program is uses ram to store data and your microprocessor to process the data. Well your graphics card can be thought of like a PC in that sense. The GPU is a microprocessor that processes data, and the video memory is the memory that gpu uses to store data. In both cases the microprocessor needs to constantly read/write data to and from memory. So in both the cases the memory and microprocessor are both important. The GPU though typically needs more memory bandwidth than the cpu does. This is because graphics work tends to involve huge throughput and massive data structures (meshes, textures, shadow maps, framebuffers, etc.). The larger these structures are the more memory bandwidth is needed.
Now the flipper uses Mosys 1T-sram with about 2.7 GB/s of bandwidth. Dolphin needs about 4.5 times as much video memory bandwidth to emulate the chip at its native resolution. This is because emulation is less efficient than the real hardware, the emulator needs to move data around a lot more often than the real hardware does.
Quote:I'm just interested in this and it would be cool if someone could write a few words about it (which are a bit more in-depth than "it's an emulator and that's why it's slower").
But that is essentially why it's slower. "It's an emulator" sums up the reasons why pretty well. If you understand what is involved with emulation then you understand why the requirements are so high.
I'm not going to respond to the rest of your posts until later since I'm ready to go to sleep now. And I'm not going to bother to read through this post and do a quick proofreading scan like a normally do. I'll get back to you in a day or two.
Those are all lists of benchmarks and of what should work or could work -- doesn't really matter. It doesn't work, and it probably can't be changed. I'd just be interested in what kinds of heavy tasks are performed on the graphics card, when comparing with a native application.