Bring DirectX to Linux! This is a Open Source DirectX implementation for Linux, providing native support for DirectX-based applications and games, without relying on Wine's Windows compatibilit...
you still have additional function calls and overhead wrapping lower level libraries
But it all happens at compile time. That’s the difference.
You probably wouldn’t consider C code non-native
This goes back to your point above:
It’s like when people say a language is “a compiled language” when that doesn’t really have much to do with the language
C is just a language, it’s not native. Native means the binary that will execute on hardware is decided at compile time, in other words, it’s not jitted for the platform it’s running on.
usually you consider compilers that use C as a backend to be native code compilers too
I assume you’re not talking about a compiler that generates C code here, right? If it’s outputting C, then no, it’s not native code yet.
so why would you consider HLSL -> SPIR-V to be any different?
Well first off, games don’t ship with their HLSL (unlike OGL where older games DID have to ship with GLSL), they ship with DXBC/DXIL, which is the DX analog to spir-v (or, more accurately, vice versa).
Shader code is jitted on all PC platforms, yes. This is why I said above that shader code has its own quirks, but on platforms where the graphics API effectively needs to be interpreted at runtime, the shaders have to be jitted twice.
I’d just point out, for running an executable, wine isn’t JITting anything at least as far as I’m aware. They’ve implemented the code necessary to read .exe files and link them, and written replacements libraries for typical windows DLLs, that are implemented using typical Linux/POSIX functions. But since, in most cases, Linux and windows runs on the same target CPU instructions set most of the windows code is runnable mostly as is, with some minor shim code when jumping between Linux calling conventions to windows calling conventions and back again.
Of course, this may be different when wine isn’t running on the same target CPU as the windows executable. Then there might be JITing involved. But I’ve never tested wine in such a situation, thoughI’d expect wine to just not work in that case.
Yes, the jitting is specific to the graphics APIs. DXVK is doing runtime translation from DX to VK. When possible, they are certainly just making a 1:1 call, but since the APIs aren’t orthogonal, in some cases it will need to store state and “emulate” certain API behavior using multiple VK calls. This is much more the case when translating dx9/11.
But it all happens at compile time. That’s the difference.
No, when you have a library like SDL you will have functions that wrap lower level libraries for interacting with the screen and devices. At SDL’s compile time you may have preprocessor macros or whatever which select the implementation of these functions based on the platform, but at run time you still have the extra overhead of these SDL function calls when using the library. The definitions won’t be inlined, and there will be extra overhead to provide a consistent higher level interface, as it won’t exactly match the lower level APIs. It doesn’t matter if it’s compiled, there’s still overhead.
C is just a language, it’s not native. Native means the binary that will execute on hardware is decided at compile time, in other words, it’s not jitted for the platform it’s running on.
Wine doesn’t really involve any jitting, though, it’s just an implementation of the Windows APIs in the Linux userspace… So, arguably it’s as native as anything else. The main place where JIT will occur is for shader compilation in DXVK, where the results will be cached, and there is still JIT going on on the “native windows” side anyway.
If you don’t consider C code compiled to native assembly to be native, then this is all moot, and pretty much nothing is native! I agree that C is just a language so it’s not necessarily compiled down to native assembly, but if you don’t consider it native code when it is… Then what does it mean to be native?
the binary that will execute on hardware is decided at compile time
This is true for interpreted languages. The interpreter is a fixed binary that executes on hardware, and you can even bake in the program being interpreted into an executable! You could argue that control flow is determined dynamically by data stored in memory, so maybe that’s what makes it “non-native”, but this is technically true for any natively compiled binary program too :). There’s a sense in which every program that manipulates data is really just an interpreter, so why consider one to be native and not the other? Even native assembly code isn’t really what’s running on the processor due to things like microcode, and arguably speculative execution is a fancy kind of JIT that happens in hardware which essentially dynamically performs optimizations like loop unrolling… It’s more of a grey area than you might think, and nailing down a precise mathematical definition of “native code” is tricky!
I assume you’re not talking about a compiler that generates C code here, right? If it’s outputting C, then no, it’s not native code yet.
But it will be native code :). Pretty much all compilers go through several translation steps between intermediate languages, and it’s not uncommon for compilers to use C as an intermediate language, Vala does this for instance, and even compilers for languages like Haskell have done this in the past. C is a less common target these days, as many compiler front ends will spit out LLVM instead, but it’s still around. Plus, there’s often more restricted C-like languages in the middle. Haskell’s GHC still uses Cmm which is a C-like language for compilation, for example.
Well first off, games don’t ship with their HLSL (unlike OGL where older games DID have to ship with GLSL), they ship with DXBC/DXIL, which is the DX analog to spir-v (or, more accurately, vice versa).
Sure, and arguably it’s a little different to ship a lower level representation, but there will still be a compilation step for this, so you’re arguably not really introducing a new compilation step anyway, just a different one for a different backend. If you consider a binary that you get from a C compiler to be native code, why shouldn’t we consider this to be native code :)? It might not be as optimized as it could have been otherwise, but there’s plenty of native programs where that’s the case anyway, so why consider this to be any different?
Ultimately the native vs. non-native distinction doesn’t really matter, and arguably this distinction doesn’t even really exist — it’s not really easy to settle on a formal definition for this distinction that’s satisfying. The only thing that matters is performance, and people often use these things such as “it’s a compiled language” and “it has to go through fewer translation layers / layers of indirection” as a rule of thumb to guess whether something is less efficient than it could be, but it doesn’t always hold up and it doesn’t always matter. Arguably this is a case where it doesn’t really matter. There’s some overhead with wine and DXVK, but it clearly performs really well (and supposedly better in some cases), and it’s hard to truly compare because the platforms are so different in the first place, so maybe it’s all close enough anyway :).
Also to be clear, it’s not that I don’t see your points, and in a sense you’re correct! But I don’t believe these distinctions are as mathematically precise as you do, which is my main point :). Anyway, I hope you have a happy holidays!
Ultimately the native vs. non-native distinction doesn’t really matter, and arguably this distinction doesn’t even really exist
Alright. Just letting you know you’re going to have a hard time communicating with people in this industry if you continue rejecting widely accepted terminology. Cheers.
But it all happens at compile time. That’s the difference.
This goes back to your point above:
C is just a language, it’s not native. Native means the binary that will execute on hardware is decided at compile time, in other words, it’s not jitted for the platform it’s running on.
I assume you’re not talking about a compiler that generates C code here, right? If it’s outputting C, then no, it’s not native code yet.
Well first off, games don’t ship with their HLSL (unlike OGL where older games DID have to ship with GLSL), they ship with DXBC/DXIL, which is the DX analog to spir-v (or, more accurately, vice versa).
Shader code is jitted on all PC platforms, yes. This is why I said above that shader code has its own quirks, but on platforms where the graphics API effectively needs to be interpreted at runtime, the shaders have to be jitted twice.
I’d just point out, for running an executable, wine isn’t JITting anything at least as far as I’m aware. They’ve implemented the code necessary to read .exe files and link them, and written replacements libraries for typical windows DLLs, that are implemented using typical Linux/POSIX functions. But since, in most cases, Linux and windows runs on the same target CPU instructions set most of the windows code is runnable mostly as is, with some minor shim code when jumping between Linux calling conventions to windows calling conventions and back again.
Of course, this may be different when wine isn’t running on the same target CPU as the windows executable. Then there might be JITing involved. But I’ve never tested wine in such a situation, thoughI’d expect wine to just not work in that case.
Yes, the jitting is specific to the graphics APIs. DXVK is doing runtime translation from DX to VK. When possible, they are certainly just making a 1:1 call, but since the APIs aren’t orthogonal, in some cases it will need to store state and “emulate” certain API behavior using multiple VK calls. This is much more the case when translating dx9/11.
No, when you have a library like SDL you will have functions that wrap lower level libraries for interacting with the screen and devices. At SDL’s compile time you may have preprocessor macros or whatever which select the implementation of these functions based on the platform, but at run time you still have the extra overhead of these SDL function calls when using the library. The definitions won’t be inlined, and there will be extra overhead to provide a consistent higher level interface, as it won’t exactly match the lower level APIs. It doesn’t matter if it’s compiled, there’s still overhead.
Wine doesn’t really involve any jitting, though, it’s just an implementation of the Windows APIs in the Linux userspace… So, arguably it’s as native as anything else. The main place where JIT will occur is for shader compilation in DXVK, where the results will be cached, and there is still JIT going on on the “native windows” side anyway.
If you don’t consider C code compiled to native assembly to be native, then this is all moot, and pretty much nothing is native! I agree that C is just a language so it’s not necessarily compiled down to native assembly, but if you don’t consider it native code when it is… Then what does it mean to be native?
This is true for interpreted languages. The interpreter is a fixed binary that executes on hardware, and you can even bake in the program being interpreted into an executable! You could argue that control flow is determined dynamically by data stored in memory, so maybe that’s what makes it “non-native”, but this is technically true for any natively compiled binary program too :). There’s a sense in which every program that manipulates data is really just an interpreter, so why consider one to be native and not the other? Even native assembly code isn’t really what’s running on the processor due to things like microcode, and arguably speculative execution is a fancy kind of JIT that happens in hardware which essentially dynamically performs optimizations like loop unrolling… It’s more of a grey area than you might think, and nailing down a precise mathematical definition of “native code” is tricky!
But it will be native code :). Pretty much all compilers go through several translation steps between intermediate languages, and it’s not uncommon for compilers to use C as an intermediate language, Vala does this for instance, and even compilers for languages like Haskell have done this in the past. C is a less common target these days, as many compiler front ends will spit out LLVM instead, but it’s still around. Plus, there’s often more restricted C-like languages in the middle. Haskell’s GHC still uses Cmm which is a C-like language for compilation, for example.
Sure, and arguably it’s a little different to ship a lower level representation, but there will still be a compilation step for this, so you’re arguably not really introducing a new compilation step anyway, just a different one for a different backend. If you consider a binary that you get from a C compiler to be native code, why shouldn’t we consider this to be native code :)? It might not be as optimized as it could have been otherwise, but there’s plenty of native programs where that’s the case anyway, so why consider this to be any different?
Ultimately the native vs. non-native distinction doesn’t really matter, and arguably this distinction doesn’t even really exist — it’s not really easy to settle on a formal definition for this distinction that’s satisfying. The only thing that matters is performance, and people often use these things such as “it’s a compiled language” and “it has to go through fewer translation layers / layers of indirection” as a rule of thumb to guess whether something is less efficient than it could be, but it doesn’t always hold up and it doesn’t always matter. Arguably this is a case where it doesn’t really matter. There’s some overhead with wine and DXVK, but it clearly performs really well (and supposedly better in some cases), and it’s hard to truly compare because the platforms are so different in the first place, so maybe it’s all close enough anyway :).
Also to be clear, it’s not that I don’t see your points, and in a sense you’re correct! But I don’t believe these distinctions are as mathematically precise as you do, which is my main point :). Anyway, I hope you have a happy holidays!
Alright. Just letting you know you’re going to have a hard time communicating with people in this industry if you continue rejecting widely accepted terminology. Cheers.