It's basically a list of linux functions that correspond to windows functions.
No, it's not. It has to be API-compatible, so that you can run a Windows binary without need for modifications. This presents some interesting challenges, because the Windows executable file format and calling conventions differ from Linux's.
Wine doesn't re implement them, it just translates them into linux native api calls (hence translation layer and not reimplementation layer) .
It runs atop Linux, so obviously uses
Linux API calls to implement the Windows API, but there often aren't exact 1:1 equivalents.
There was a fairly high-profile example of Windows' WaitForMultipleObjects()
function that had no direct equivalent on Linux, until fairly recently. It actually motivated the development of a new kernel synchronization construct, called Futex2.
The same goes for gpu as well, if there is a native linux API that supports a command wine uses that otherwise that command/function won't work.
No, that's not how Direct3D is emulated. Yes, at some level, there needs to be support by the hardware & its device driver for whatever D3D features a program is trying to use, but it's not a trivial 1:1 translation. For one thing, you're glossing completely over the fact that a lot of GPU code runs on the GPU, itself, and has to be translated since Linux GPU drivers don't natively understand D3D HLSL.
If the linux API is more optimized it can end up being faster than running it on windows "natively" .
I think it's pretty rare for a game to run faster under WINE than natively on Windows. It's happened, but not the norm.