Time for another GamingOnLinux interview! This time, we have someone who many that follow Valve and Steam Play Proton will be familiar with - it's Joshua Ashton.
GOL: Firstly, can you introduce yourself?
GOL: How did you get started with coding, what pulled your interest in to really get going with it?
"I’ve been programming (or trying to) in some form since I was about 7 years old. I don’t really remember all the details other than something something hello world tutorials and GDI Pong but I’ve just really constantly been playing with trying to write stuff.
I started to take things more seriously and consider it as what I wanted to do when I was in secondary school and writing little basic engines of my own and mods for games.
I also quite liked doing theatre (I’m more qualified in that than comp sci/software engineering) and I still do, but I don’t think it would be sustainable as a profession so I mostly just stick to doing local shows and local amateur theatre as a hobby.
From then on I have mainly just been bashing rocks together to learn -- I hate reading books or anything like that.
I did DXUP and started D9VK as a personal project while I was in sixth-form (last two years of high-school for you Americans) and kinda went from there."
GOL: You’re the creator of D9VK (Direct3D 9 to Vulkan) which got pulled into DXVK (now Direct3D 9/10/11 to Vulkan). And now you’re helping with projects like VKD3D-Proton too? Could you tell us a little about the work involved in all this and how you got involved originally?
"Hmmm, this is a long story.
Originally I started work on DXUP to play Just Cause 2 on Linux translating D3D10->D3D11. Then, my friend Sam thought it would be cool to try and get Blade Symphony and Source working on Windows Phone, but that only supported D3D11 so I started adding D3D9 support to that and got a few games working with that -- I think by that point I gave up trying to make it work on Windows Phone and it was just a cool project to see what I could do. It was also interesting on Linux for use with DXVK.
I was then at a conference and I was talking with some people about potentially doing a D3D9 -> Vulkan layer and I was told that it “was a waste of time” and that I “couldn’t do it and should work on something else”.
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.
I went in completely blind, I had very little knowledge about Vulkan other than making a triangle from some tutorial.
The DXVK backend did a lot of the heavy-lifting but I still had to translate all the shaders, state and all of the bizarre D3D9 edge cases myself though.
After a few weeks it was running some basic demos, and after a couple months, A Hat in Time.
Since then it’s been merged into DXVK and the default in Proton for some time.
I am glad that my petty arrogance turned into something that helps people for once…
As for vkd3d-proton, my work there started with sorting out moving to Meson, and building as PE (a .dll rather than a .so) while I was travelling. I don’t contribute there that often, but I will do the odd cleanup, issue investigation or feature implementation (like VRS or 64-bit floating point in DXBC, etc) every now and again."
GOL: You also made DXVK-Native, could you tell us a little about it?
"DXVK Native is basically just DXVK with support for building natively on Linux, and it’s what is being shipped in Portal 2 and Left 4 Dead 2 right now for -vulkan. All of the Windows-isms are either removed or replaced with SDL stuff. For example, a HWND is now just an SDL_Window. It’s very easy to add a WSI abstraction to DXVK Native, you could easily make one for GLFW or directly for X11 or Wayland, I just haven’t had the time to.
I’ve been meaning to do proper releases with binaries built in the Steam Runtime and better documentation for it, but it doesn’t have any customers other than me yet.
If anyone is interested in using it to help with your own native ports, please get in touch."
GOL: What’s it like to work for Valve under contracts? How did that happen?
"I like that I get to work on a lot of different things, from DXVK and VKD3D-Proton, Vulkan Spec work, RADV, the back catalogue games and more -- I have a lot of trouble just working on one thing for a long time having the ability to move around helps me a lot.
I feel very privileged that I get to work with a bunch of amazing people and make great things that make people happy!"
GOL: You’re also responsible for getting Vulkan into Portal 2 through DXVK. Who approached who to make that happen? What’s it like hooking up such a new API to an older engine?
"DXVK Native had existed in some form for over a year at this point but it never really had any real world testing anywhere.
The bulk of the work there was actually having to maintain compatibility with ToGL (the D3D9->GL layer that the game previously used) at the same time.
ToGL has a lot of hacks upon hacks on-top of D3D9 for stuff like determining if a texture is a shadow, depth bias, etc or doing something slightly different somewhere in the engine or game code.
If I was handed the game ported without ToGL, then in theory it would actually be easier in the end as DXVK Native is entirely drop-in and it just works, as it doesn’t require any of these workarounds."
GOL: You’ve also helped with other games too, like the upcoming Portal 2: Desolation. Could you tell us a little about what to expect and what your work there involved?
"I guess I am the lead programmer for that, alongside Josh Dowell (Slartibarty) and Sam Pavlovic. Mainly I work on graphics there, we have our own custom DXVK Native with a bunch of extended interfaces with extra features -- for both performance and visual fidelity.
It’s a pretty ambitious project, I think we’re aiming for around 50-ish tests for release as well as a very gripping and poignant story. It’s a long way off, primarily because of the scope, so definitely no concrete release date set at the moment; but there is constant progress being made all the time!
We have an in-lore “consumer catalogue” available for you to read online too: https://emberspark.games/desolation/catalog/
For GOL I also have some sneak-peak images of the last 3 Steam Screenshots I took in it 🐸:"
GOL: For us non-desktop coders, we’ve all heard how Vulkan is far more difficult than OpenGL. Just how hard is it to work with Vulkan?
"Well, it’s an entirely different approach to graphics programming -- in Vulkan you’re defining all the different bits of pipeline state explicitly, all the descriptors and command buffers to execute (and all the synchronization), whereas in GL, you basically just tell the “OpenGL Machine” what you want to do. It’s kind of like the difference between driving a car and going straight and doing a right turn, to assembling the car yourself such that it will go straight and then do a left turn.
There’s a very steep curve at the start, but once you start to understand that the spec is your friend, not your enemy and get past all the hassle of doing the initial stuff to render a triangle, things become much easier.
That being said, it’s definitely not for everyone, or for every use case (directly). Porting older codebases to use Vulkan directly is painful if you want to do it correctly and want the key benefits of Vulkan out of it.
I would still definitely recommend GL/DX11 for people wanting to learn graphics, simply because it’s so easy to get into.
I’m really not a big lover of GL myself though, I find it just to be a messy pile of “how can we add X feature into the API without breaking any backwards compatibility”. In my opinion, GL versions should have been entirely different interfaces, not just extending the same horrible design from well before I was born forevermore."
GOL: What are your thoughts on tech like Ray Tracing, NVIDIA’s DLSS and AMD’s recent announcement of Super Resolution?
"I think DLSS is cool and definitely a technical marvel -- but despite it having really impressive results, there is a part deep down inside me where it feels wrong that this is what we should be relying on going forward. I do think it’s a very good stop-gap until we find better solutions to make real-time raytracing more viable performance wise.
FSR is rather cool and has impressive results for being non-temporal but as I understand it, it doesn’t solve all the same problems DLSS does -- it only handles the upscaling part, so you’d still need to bring your own AA (which very well may be temporal) which you don’t have to do with DLSS."
GOL: Thoughts on the Valve Steam Deck?
"I am happy that it’s finally out there and I am excited to play stuff on it. :D I have wanted something like this for such a long time personally. I have a pretty large back catalogue of older titles I’ve been meaning to play through so maybe this will give me a chance to get through those.
I am very proud to work with a bunch of amazing people on the technology behind it!"
GOL: Any fun plans for the future?
"Definitely, but I’m not sure what I can say that is specific :P I am working on a few misc. personal side projects but nothing that I really want to share yet. Other than that, just keeping on frogging! 🐸"
A big thank you to Joshua Ashton for spending some free time to answer our questions!