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.
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.
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"?
You can. You don't have to contribute back. That's the whole concept of forking.
Actually, can they legally make improvements and not contribute the changes back upstream?It's fine, and I bet that 95% of the changes they had to do to make things work in a driver environment wouldn't be very useful for us anyway.
They are far better off with a hard fork anyway. Get rid of things they don't need, change things to make WHQL stuff pass (we got bug reports from them about that, which unfortunately were pretty much completely useless for us), maybe change a few things here and there to be more efficient on their Vulkan driver (Steam Deck hardware is obviously higher priority for us). In the long term, refactor the D3D9 front-end to implement the DDI natively.
All of this is allowed, and honestly, the less we have to worry about it, the better.
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"?The GPL says you have to provide all the code, including your changes, to the people you distribute the software to. "Upstream", by whatever name, isn't a concept in the GPL. And I think this is by design; the GPL is intended to as it were democratize software, not to give more power to original developers or central repositories.
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”.
And he was 17yo when he started it:
That really annoyed me, and like, I know I was pretty young (17) at the time, but I felt like I was being treated like some dumb kid. So I started D9VK as a spite project that night in my hotel room.
This is how you get those amazing peoples that gives wonderful piece of software to us, poor mortals.
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"?
Requirement to provide any modifications as open source that GPL has is usually called "strong copyleft". Licenses like Zlib allow modifications to be distributed without requirement to provide the source code. That's called "weak copyleft".
Last edited by Shmerl on 8 December 2022 at 11:18 pm UTC
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`.
Oooh, yeah. I somehow missed that :D
(Although this reminds me of how *hard* it is to do "case insensitive matching" in an international way. Is `i` equivalent to `I` or to `İ`? :D)
SynchroAnarchy Dec 15, 2022
Patreon
PayPal
See more from me