Support us on Patreon
PayPalIntel recently announced a big driver update for their Arc GPUs on Windows, because their DirectX 9 performance wasn't as good as it could have been. Turns out, they're using code from the open source DXVK which is part of Steam Play Proton.
Translation layers are everywhere it seems, especially for older software and APIs now.
DXVK translates Direct3D 9, Direct3D 10 and Direct3D 11 to Vulkan. Primarily written for Wine, the Windows compatibility layer, which is what Proton is made from (Proton is what the majority of games on Steam Deck run through). However, it also has a Native implementation for Linux and it can be used even on Windows too. So it's not a big surprise to see this. Heck, even NVIDIA use DXVK for RTX Remix.
In their announcement video below, they talk about how they did a "native implementation of DX9" and "there will be times when games are running on our native DX implementation, but there'll be other times when we take advantage of translation layers to go from DX 9 to a more modern API". Their blog post also mentions this hybrid approach, but neither the blog post nor video actually say it's DXVK. You only find that out when you look through their readme, to find the DXVK note and license.
They say the way it works will be transparent to the end user, so they likely just have a list of games where the driver switches between DXVK or their own work.
Direct Link
It's amazing to see open source everywhere.
While this isn't for Linux directly, the more companies that end up using the same translation tools we use, the better they could get. Hopefully Intel will also end up helping with DXVK work from this too and not keep any improvements to themselves.
Article taken from GamingOnLinux.com.
Quoting: WorMzySomeone needs to tell "Longhorn" about grep -i. >_>
Lol. I use rg -i these days.
Quoting: ShmerlHm, original license is Zlib, so it's not strong enough as GPL to prevent Intel from doing such shady stuff. However it mentions this:They include the license as-is, so it's perfectly legal to use the DXVK code like they are AFAIK.
Quote– Altered source versions must be plainly marked as such, and must not
be misrepresented as being the original software.
Last edited by Liam Dawe on 7 December 2022 at 11:47 pm UTC
Quoting: Liam DaweThey include the license as-is, so it's perfectly legal to use the DXVK code like they are AFAIK.
At least release notes mention DXVK developers.
But I wonder what's their motivation for such obfuscation in the code in the first place. It's going some extra length for sure.
Last edited by Shmerl on 7 December 2022 at 11:50 pm UTC
Quoting: ShmerlBut I wonder what's their motivation for such obfuscation in the code in the first place. It's going some extra length for sure.At a guess: stripping out what they don't need, and hacking away at DXVK to make it work to do what they need inside the driver.
ElectricPrism Dec 8, 2022
By making these projects part of the cogs and wheels we secure our future and all silicon leads to LINUX like all roads to ROME.
Quoting: Liam DaweQuoting: ShmerlBut I wonder what's their motivation for such obfuscation in the code in the first place. It's going some extra length for sure.At a guess: stripping out what they don't need, and hacking away at DXVK to make it work to do what they need inside the driver.
Yeah, they have few PR's on DXVK github also (by adamjer, who works at intel) that haven't been merged due to some problems, but at least it seems they contribute back.
Quoting: GuestQuoting: WorMzySomeone needs to tell "Longhorn" about grep -i. >_>
I was thinking the same thing! :)
Given he's a "Kernel/hypervisor engineer", that ugly use of the cli makes me wonder about the quality of their code...
Am I missing something? No idea why `grep -i` directly would be better than using `strings` first. The former would print all *lines* matching the regex which is absolutely less useful, especially in a binary context where "lines" are just bytestrings that happen to be delimited by a 0xA byte. So the output would also be less useful due to the whole line being matched. You could change that using the `grep -o` option but that's GNU only. Further, this is probably even more efficient, since grep matching potentially huge lines is not a good starting point.
So this is actually the way to go: Converting a binary into a text "file" (a list of strings) and then using a text tool to work on this further. That's what pipelines are for.
Quoting: ShmerlQuoting: Liam DaweThey include the license as-is, so it's perfectly legal to use the DXVK code like they are AFAIK.
At least release notes mention DXVK developers.
But I wonder what's their motivation for such obfuscation in the code in the first place. It's going some extra length for sure.
Higher ups with little technical understanding not informed well about it and engineers don't want it to be seen as "just used a library" by them, seems likely.
Quoting: ljrkQuoting: GuestQuoting: WorMzySomeone needs to tell "Longhorn" about grep -i. >_>
I was thinking the same thing! :)
Given he's a "Kernel/hypervisor engineer", that ugly use of the cli makes me wonder about the quality of their code...
Am I missing something? No idea why `grep -i` directly would be better than using `strings` first. The former would print all *lines* matching the regex which is absolutely less useful, especially in a binary context where "lines" are just bytestrings that happen to be delimited by a 0xA byte. So the output would also be less useful due to the whole line being matched. You could change that using the `grep -o` option but that's GNU only. Further, this is probably even more efficient, since grep matching potentially huge lines is not a good starting point.
So this is actually the way to go: Converting a binary into a text "file" (a list of strings) and then using a text tool to work on this further. That's what pipelines are for.
They're referring to the first three lines, where the person on twitter tried different spellings for DXVK (Dxvk, dxvk, DXVK), which could've been handled by `-i`.
Last edited by cprn on 8 December 2022 at 12:25 pm UTC
See more from me