Hacker News new | past | comments | ask | show | jobs | submit login

Someone better educated than me can probably help me out here, but I think you're either misunderstanding what some things are, or mixing up your terminology.

Proton is the emulation layer created by Valve.

Vulkan is a cross-platform graphics API.

Your point might still stand, but it's worth debating. Without Proton, gaming on Linux is limited to native Linux games. With it, the story changes. Someone who likes PC gaming might be willing to turn Linux into their daily driver, game on Linux (with a mix of Proton and Vulkan), and now the market starts to support developers making more native Linux games, where they otherwise might not.




I was not mentioning Proton explicitly. But the core of my point is that Proton de-facto delegates Vulkan to be a second class citizen whose purpose it is to serve as a backend of implementing a Microsoft-compatible technology stack. With Proton working well, the incentive to develop native Linux applications and games goes to wards zero — why would you even bother if you can just develop and test for Windows and let the Proton maintainers sort out the rest?

Currently, there are some games that use Vulkan to target both Windows and Linux. Proton encourages the developers to use the Microsoft technology stack instead. Apple has their own Metal, so Vulkan is dead in the water there anyway. Where does this leave Vulkan? Android? That is likely to move to WebGPU as I mentioned. GPGPU? That is totally dominated by CUDA and other vendor-specific APIs. Linux pro applications (Blender)?


If there is a native Vulkan backend there is little reason for an API emulation layer with an identical before-and-after to not just forward the calls on as much as possible - especially with an API which makes its state a lot more explicit and keeps less internal state.

With that said, as a game dev, Vulkan - along with DirectX and OpenGL - are second-class citizens already. The large bulk of gamedev is concerned with content, gameplay systems, and UI, with graphics being on the long tail of things that can make a title look truly unique and great, but the prevalence of Unity and Unreal make the actual rendering pipeline a thing of secondary - hugely important, but not primary - concern to most titles.


This comment is loaded with some pretty unrealistic conclusions. Firstly, Vulkan support is becoming extremely common even on Windows-exclusive titles.

> Apple has their own Metal, so Vulkan is dead in the water there anyway.

How is Apple at all relevant in a thread about games? Apple has proactively shut out gaming in the past few years. Metal is almost exclusively used to draw fancy GUIs.

Furthermore, DXVK is an open source (strictly) project. Who honestly cares who came up with the API? People even run DXVK on Windows because it often offers superior performance.

There are some very big studios getting behind Vulkan: Embark, id.

As to the root comment: https://en.m.wikipedia.org/wiki/Stanford_marshmallow_experim...


What defnition of "extremely common" are we working with here? PCGW lists 151 games [0] with Vulkan support of any kind (not neccessarily on Windows).

Meanwhile there are 188 with DirectX 12 support [1] and 2723 with DirectX 11 support [2].

Don't get me wrong, I too would like for the open cross-platform API to win, but so far support is far from extemely common.

[0] https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

[1] https://www.pcgamingwiki.com/wiki/List_of_DirectX_12_games

[2] https://www.pcgamingwiki.com/wiki/List_of_DirectX_11_games

> As to the root comment: https://en.m.wikipedia.org/wiki/Stanford_marshmallow_experim...

Could you expand on what you are trying to argue? It seems to me that Proton is the immediate reward while waiting for the platform to grow to get native ports would be the delayed reward. Yet "In follow-up studies, the researchers found that children who were able to wait longer for the preferred rewards tended to have better life outcomes" would support the caution against Proton if you were to generalize from children to platform strategies (not saying that you should).


If I may, I suspect your angle on this might be slightly askew at least from my perspective. Almost all the major game engines are now supporting a native vulkan/linux renderer. I'm running in godot 4 right now. If anything, watching things like glorious eggrolls proton and the dxvk repo [1] I think the people working at the direct translation level are causing more eyes on vulkan than it would otherwise be getting.

My actual concern for proton/wine on linux is security related. The binary game space is a security nightmare, and enabling the windows side to run with very little compartmentalization is going to be a security disaster.

1. https://github.com/doitsujin/dxvk


Are you saying it's the case that running a game on Proton on Linux is a superior experience to running it natively on Vulkan?

That's surprising to me, but yes, if it's better than a native graphics API, it's probably better for everyone if developers stick to DirectX.

On the other hand, I don't think you addressed my point (with my assumption that games run better natively on Linux in Vulkan). If gamers are just going to skip Linux entirely without Proton, how is that better for Linux gaming, than if gamers migrate to Linux using Proton for an acceptable emulated experience, then there are more Linux gamers, and developing for Vulkan has some incentive it didn't have before.


> If gamers are just going to skip Linux entirely without Proton

Gaming on Linux was a thing before Proton and so far, it has not brought a giant jump in Linux users - e.g. Steam hwsurver still has Linux users hovering at about 1% [0]. Maybe that will change but so far this argument falls flat.

[0] https://store.steampowered.com/hwsurvey/


It doesn't look like it brought about a massive increase, but Linux gaming has increased[0] about 25% over the 3 years since Proton was released.

(25% of 0.8% is 0.2%! Ha!)

[0] https://www.pcmag.com/news/percentage-of-linux-gamers-on-ste...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: