Intel 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.
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
gradyvuckovic Dec 7, 2022
Maybe AMD could use Bink for Windows to translate from OpenGL to Vulkan too. Given how slow OpenGL is on AMD/Windows, I doubt Bink could be any slower.
3 Likes, Who?
Remember, this is a project that was deemed a “a waste of time”. The developer was told they “couldn’t do it and should work on something else”. 
29 Likes, Who?
Interesting, but not giving credit by name to the project they directly benefit from is very poor taste, especially when they boast about performance improvements which no doubt prompted them to turn to dxvk in the first place.
Last edited by Shmerl on 7 December 2022 at 11:23 pm UTC
Last edited by Shmerl on 7 December 2022 at 11:23 pm UTC
19 Likes, Who?
Remember, this is a project that was deemed a “a waste of time”. The developer was told they “couldn’t do it and should work on something else”.Now that's a hilarious thing to bring up.
4 Likes, Who?
Interesting, but not giving credit by name to the project they directly benefit from is very poor taste, especially when they boast about performance improvements which no doubt prompted them to turn to dxvk in the first place.I did find it a little weird, how they kept praising their own engineers but couldn't even name DXVK itself.
20 Likes, Who?
Proton (DXVK) is starting on it's path to take over Windows aswell.
1 Likes, Who?
The plot thickens, even though they're clearing using DXVK and include the license they seemingly tried scrubbing mentions of it away (see the whole thread there). Hopefully they at the very least put their changes out in the open and not keep their forked code closed.
Last edited by Liam Dawe on 7 December 2022 at 11:40 pm UTC
Last edited by Liam Dawe on 7 December 2022 at 11:40 pm UTC
7 Likes, Who?
The plot thickens, even though they're clearing using DXVK and include the license they seemingly tried scrubbing mentions of it away (see the whole thread there). Hopefully they at the very least put their changes out in the open and not keep their forked code closed.Someone needs to tell "Longhorn" about grep -i. >_>
4 Likes, Who?
Now, these are exciting news! It's great to see DXVK getting traction outside of WINE. First Virtualbox starts using it for 3d acceleration, now intel uses it in their drivers... More users and potential contributors. At this pace, it might even dethrone VMWare's solution as the best 3d acceleration solution for windows guests (outside of intel gvt-g, nvidia vgpu and gpu passthrough).
Maybe AMD could use Bink for Windows to translate from OpenGL to Vulkan too. Given how slow OpenGL is on AMD/Windows, I doubt Bink could be any slower.AMD has actually finally started fixing their OpenGL drivers, the 22.8 drivers nearly doubled performance in doom 2016, teardown and minecraft on my rx 5700 under windows. It doesn't quite match radeonSI, but it's a huge improvement nonetheless.
2 Likes, Who?
Hm, original license is Zlib, so it's not strong enough as GPL to prevent Intel from doing such shady stuff. However it mentions this:
– Altered source versions must be plainly marked as such, and must not
be misrepresented as being the original software.
6 Likes, Who?
Someone needs to tell "Longhorn" about grep -i. >_>
Lol. I use rg -i these days.
1 Likes, Who?
Hm, 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.
– 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
0 Likes
They 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
2 Likes, Who?
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.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.
2 Likes, Who?
ElectricPrism Dec 8, 2022
Some people may have mixed feelings about this, but this is a great thing when your work is awesome enough to be used by the big guys.
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.
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.
1 Likes, Who?
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.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.
5 Likes, Who?
Someone 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.
1 Likes, Who?
They 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.
0 Likes
Someone 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`.
1 Likes, Who?
Actually, can they legally make improvements and not contribute the changes back upstream? Doesn't Zlib license forbid that? I know it doesn't say so explicitly but it was approved by FSF and I though all FSF approved licenses were based on this premise. Also, if it doesn't, how can it be described as "compatible with GPL"?
Last edited by cprn on 8 December 2022 at 12:25 pm UTC
Last edited by cprn on 8 December 2022 at 12:25 pm UTC
0 Likes
Patreon
PayPal
See more from me