Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

It's happened, the D9VK and DXVK projects have officially merged. This means DXVK is now the all-encompassing project to translate D3D 9/10/11 to Vulkan for Wine.

Only a few hours ago the pull request was accepted and so they're now one awesome project, meaning D9VK will now be developed directly in the DXVK project. This does make a lot of things easier and simpler overall, since you only need to keep track of one project and they will now update together.

From the actual pull request, Ashton noted these features still needed to be worked on:

  • Fixed function bumpmapping
  • Fixed function premodulation
  • Software cursor (hardware cursor is currently implemented)
  • ComposeRects (from D3D9Ex, however I have no test case for this)
  • Custom Border Color (needs ext)
  • Depth Bias Fixes (needs ext)

Apart from that, the usual bug fixing.

Congratulations to D9VK developer Joshua Ashton and DXVK developer Philip Rebohle, together they've certainly helped pushed Linux gaming into new territory.

Article taken from GamingOnLinux.com.
Tags: Update, Vulkan, Wine
51 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
38 comments
Page: «4/4
  Go to:

BrazilianGamer Dec 16, 2019
That's just... Remarkable. DX12 Vulkan implementation, we're waiting for you
Creak Dec 16, 2019
Quoting: ShmerlRust is a thing today. I'd take Rust over C++ and for sure over C. And you phrased it very well: "the more it goes, the less I want to code in C or C++". I have the same exact feeling, when there is a better designed language.
Yup, I would go the Rust way as well. I'd say that, as of today, the community knowledge and resources are not as good as for C and C++ (think stackoverflow and C/C++ libraries). But I truly hope Rust will continue to be more and more popular.

Off-topic: I don't agree with all the language decisions in Rust, notably the different behavior just if you prefix your variable with `_`:
    // The compiler warns about unused variable bindings; these warnings can
    // be silenced by prefixing the variable name with an underscore
    let _unused_variable = 3u32;

Knowing that there is already a way, which is clearer IMO, to silence some warning. See first lines in https://doc.rust-lang.org/stable/rust-by-example/custom_types/enum/enum_use.html
ziabice Dec 16, 2019
Good job, Joshua! <3
Shmerl Dec 16, 2019
Quoting: CreakOff-topic: I don't agree with all the language decisions in Rust, notably the different behavior just if you prefix your variable with `_`:
    // The compiler warns about unused variable bindings; these warnings can
    // be silenced by prefixing the variable name with an underscore
    let _unused_variable = 3u32;

Knowing that there is already a way, which is clearer IMO, to silence some warning. See first lines in https://doc.rust-lang.org/stable/rust-by-example/custom_types/enum/enum_use.html

Yeah, I suppose it can eventually get trimmed (i.e. special meaning of _), unless they have some backwards compatibility concerns about not breaking the current behavior.


Last edited by Shmerl on 16 December 2019 at 8:16 pm UTC
TheSHEEEP Dec 16, 2019
View PC info
  • Supporter Plus
Quoting: Shmerl
Quoting: CreakOff-topic: I don't agree with all the language decisions in Rust, notably the different behavior just if you prefix your variable with `_`:
    // The compiler warns about unused variable bindings; these warnings can
    // be silenced by prefixing the variable name with an underscore
    let _unused_variable = 3u32;

Knowing that there is already a way, which is clearer IMO, to silence some warning. See first lines in https://doc.rust-lang.org/stable/rust-by-example/custom_types/enum/enum_use.html

Yeah, I suppose it can eventually get trimmed (i.e. special meaning of _), unless they have some backwards compatibility concerns about not breaking the current behavior.
That's my biggest gripe with Rust.
It tries to enforce a crapload of conventions, from coding guidelines to how it focuses so much on memory safety that it makes some convenient coding rather impossible.
Basically, you code in the one way Rust wants you to, or you gtfo. Feels too restraining to me, especially considering coming from C/C++, I do know how to keep memory safe myself, I don't need that "safety net".

If the language would open up more, that would make it quite nice.
But of course, it will live or die with its supported libraries and right now, that doesn't look too great.


Last edited by TheSHEEEP on 16 December 2019 at 8:48 pm UTC
Shmerl Dec 16, 2019
Quoting: TheSHEEEPBasically, you code in the one way Rust wants you to, or you gtfo. Feels to restraining to me, especially considering coming from C/C++, I do know how to keep memory safe myself, I don't need that "safety net".

That's exactly the selling point though. You might know, but that won't prevent you from making a mistake better than the compiler (type system combined with borrow checker) would. Human factor is the biggest cause of memory related errors in C and C++. So removing it is a huge benefit.

However, the trade off is a more restrictive way of how you can approach memory structures. Making something like linked list in Rust can be surprisingly complex in comparison with C or C++ as a consequence:

https://rust-unofficial.github.io/too-many-lists/

Rust designers understood, that there are cases when borrow checker is too restrictive, that's why there is unsafe option. In fact, standard Rust library itself is using unsafe when appropriate. The outward interface remains safe though. Unsafe is also needed when interacting with non Rust modules (such as C or C++) from within Rust.

See: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html


Last edited by Shmerl on 17 December 2019 at 6:35 am UTC
Sir_Diealot Dec 17, 2019
Quoting: TheSHEEEP
Quoting: rkfg
Quoting: Eike
Quoting: rkfgDXVK has a "fundamental flaw" and that is the language it's written in. Wine doesn't accept C++ code, unfortunately.

Now I wondered what they're using.
Pure C?!?
Yes, Wine is written in pure C.
Guess that is one way to make sure a project never has too many people working on it.
What a waste of potential.

Pure C is fine for smaller projects or concise little libraries.
But big ones purely in C is just nightmare fuel. Go take a look at the FFmpeg sources if you don't believe me.

Alright, merge Wine into DXVK, then ;)
C++ isn't picky about having some pure C code within.

Well, there is this little project called Linux that is written in C.
TheSHEEEP Dec 18, 2019
View PC info
  • Supporter Plus
Quoting: Sir_Diealot
Quoting: TheSHEEEP
Quoting: rkfg
Quoting: Eike
Quoting: rkfgDXVK has a "fundamental flaw" and that is the language it's written in. Wine doesn't accept C++ code, unfortunately.

Now I wondered what they're using.
Pure C?!?
Yes, Wine is written in pure C.
Guess that is one way to make sure a project never has too many people working on it.
What a waste of potential.

Pure C is fine for smaller projects or concise little libraries.
But big ones purely in C is just nightmare fuel. Go take a look at the FFmpeg sources if you don't believe me.

Alright, merge Wine into DXVK, then ;)
C++ isn't picky about having some pure C code within.

Well, there is this little project called Linux that is written in C.
That is a special case as it is a very, very, very old project - 30 years by now? More?
C++ was standardized in 1998, it is younger than Linux itself.
I wouldn't really want to rewrite it to C++, either, if I had been working with it in C for over a decade. At that point, no language better suited in theory will offset the sheer amount of experience. It's not like you can do anything in C++ that couldn't be done in C, it is simply easier to maintain and to code in.
And even if it did switch, what about the endless amounts of modules and packages relying on its C-Style interface.
Nonono, nobody would want to change Linux to C++ just for the sake of it being C++ then ;)


Last edited by TheSHEEEP on 18 December 2019 at 9:04 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.