(fwiw, read the two explanations on "virtual memory" and "gpu registers" at the bottom first if you have no idea what these two are)
Wine "emulates" stuff by statically recompiling (actually, it only statically
relinks) program binaries. All references to Windows API functions get replaced by references to own implementations of those functions. I.e. if a program binary tries to call IDirect3DDevice9:
rawIndexedPrimitive, Wine will execute the own implementation (i.e. the OpenGL wrapper) of that function. This works because the program binary doesn't actually contain the implementation of DrawIndexedPrimitive but only a reference to a DLL which contains the binary code for the implementation. Thus, Wine can easily patch the program binary to call the OpenGL wrapper instead of the DLL implementation.
This is why it's often called API emulation. The advantage is that it's much easier to do: The native DrawIndexedPrimitive implementation would poke some GPU registers, fill the GPUs command processor queue, etc. Emulating the behavior of those GPU registers would be much more work with effectively no gain since the only way applications access the GPU is through Direct3D (or OpenGL) anyway. I.e. API emulation is ideally just as compatible as low-level register emulation IF applications always only use the API instead of manually accessing registers anyway. (This is greatly simplified, but I hope you get the idea)
For executing Windows applications within a Linux environment, that "IF" is not much of a big deal, since there are virtually no applications which directly program the GPU. On the Wii (or console emulation in general), it's a different thing though. There's different problems which don't allow for API emulation:
a) LTCG (link time code generation) often will "copy" a function implementation into the program binary instead of just putting a reference into the binary. Obviously, we can't just replace the function implementations easily now since we don't even know where a HLE'able function sits in the program binary.
b) AFAICT, the Wii in particular doesn't even have any DLL-like libraries. Wii applications of course are compiled against the SDK libraries. However, they're not dynamically linked, but statically linked. This is similar to case a: There are no references to functions, but the function implementation code resides in the binary itself. It's a little different, because LTCG often has multiple (slightly different) function implementations which are optimized to the current usage. Static linkage probably will put a single code implementation "at the top" of the program binary (which also looks the same for all applications which linked against the same library). Thus, this issue could be worked around with some pattern checks and stuff.
c) On top of that, game programmers often don't even only use the SDK functions to access e.g. the GPU. This breaks our big "IF" from above: If a hardware device is accessed through a different mean than a standardized API, you'll end up sacrificing compatibility if you're using API emulation.
So... this was an explanation about why we can't use API emulation in Dolphin. This is one difference to Wine. There's another one as well though: Wine
can't fix issues a and c at all because it doesn't emulate a CPU. LTCG is also a reason why Cxbx and Dxbx (the most advanced xbox emulators at the moment) fail at emulating some games currently, because C/Dxbx heavily rely on detecting API calls via pattern detection (similar to Wine). For Wine, LTCG isn't such a big deal for Wine since system-libraries like Direct3D aren't LTCG'ed.
Anyway the problem is the following: If a program binary pokes a hardware register directly (either because of failed API function detection or because the programmers felt like programming the GPU directly), Wine can't detect that and will just fail/crash/do nothing.
For Dolphin, it's a different thing. We
are emulation the PPC CPU. Whenever the CPU tries to write to a certain virtual memory address*, we can check if that memory address corresponds to the GPU register set and properly emulate the GPU functionality on the register level that way.
*virtual memory: One would think that the memory which is writable by the CPU is only the RAM memory; however, it can also write to other stuff like e.g. GPU registers. All of these things are mapped to a continuous memory map called "virtual memory". Whenever the CPU tries to read from / write to the virtual memory, the MMU (memory management unit) will resolve the virtual memory address and redirect the access to the proper destination.
*GPU register (or hardware registers in general): hardware devices can expose their capabilities/configuration/etc by reserving a certain range of virtual memory. The CPU then can write to that memory range and directly program the device that way. In case of a GPU, some of the exposed features could be the command queue, some render states, etc. Each byte of the GPU registers has a certain function, e.g. if the CPU writes to the byte at a certain offset, it can tell the GPU to enable lighting in the next render call. Telling the GPU to start rendering stuff would be another register. Flipping the back buffer another one.
....
So much about the difference between Wine and Dolphin. I'll maybe elaborate a bit on the actual causes of slow GPU emulation in Dolphin in another post at a later point.
