Quoting: 3zekielThe situation indeed isn't as simple as "Nvidia evil vs good guy everyone else". Nvidia based its solution on a standard existing somewhere else (that did not pan out as expected) so they did not make a revolution in their own little world.

Actually Nvidia didn't even bother discussing the matter when the other vendors were making the choice, and decided to go for EGLStream all alone.

Then, they wanted to discuss how EGLStreams was supposed to be technically better, which lasted for quite a few years.

Then, they wanted to develop a new API, they wrote some code and put it on github, and is never went any further.

Then, when RedHat pushed for EGLStream compatibility in Fedora, it was mainlined in mutter but Nvidia was still not compatible with XWayland.

Fast forward 2021, Nvidia patches XWayland, only to give up a few months later and make their driver work with GBM.

Literally, they've been messing around for 5 years for nothing. The only visible effect of this is the harm they made to Wayland adoption and innovation on Linux at large. :shock:

Some sources:
Nvidia presenting EGLStreams in 2014 [External Link]
Nvidia wanting a new API [External Link]
Nivida's Unix Memory Allocator on Github (last updated 4 years ago) [External Link]

View this comment - View article - View full comments

Quoting: GuestOpenGL in Source-based games wasn't native too - these games use ToGL layer, which translates Direct3D calls to OpenGL calls. DXVK Native isn't any different in that way - it translates D3D to Vulkan at compile time similarly to ToGL.

...like almost every native port on Linux. (I am not really reacting to your post, it's just noteworthy since the DXVK debate has been the starting point of many flamewars)

View this comment - View article - View full comments

To me this feels like lottery.
Either developers just tick the option, or they just get frightened and don't tick the option, and Linux gaming is -- yet again -- a second-class citizen.
Whether they are going to do it or not, seriously, I don't know.

View this comment - View article - View full comments

I don't quite understand why they are invoking the need for resources, planning and QA for an unsupported use case.

View this comment - View article - View full comments

Been using Pipewire ever since it became default on Fedora and it is great so far. There are still some instabilities but nothing serious either way.

View this comment - View article - View full comments

Quoting: jens

Quoting: Schattenspiegel

Quoting: jensDefine yourself with the things you love, not with the things you hate.
(Taken from somewhere on GoL)

And true to that spirit I shouted my rejection of it into the world, that my words may become real, and it shall not define me in any way shape or form henceforth. ;-)

Very cool, cannot top that mastery of language :)

And thus, shall we repent in ashamement, for we ought to reckon such mastery and craft holds no knowledgable truth beneath.

View this comment - View article - View full comments

Quoting: Guest

Quoting: omer666Still the large majority of Linux ports use an API translation layer (Valve uses ToGL and Feral have their own technology for this.)

The fact that it's often used doesn't make it a good thing...

It's not used "often," it's used, like, almost all the time.

Quoting: GuestIt's not only the kernel. Even compilers are a problem. There have been cases when compiler xyz in version .13 (minor version) was failing to compile the code for it's prev version something that sorry to say but it's totaly dumb.
The problem i talk about is not Mesa only, the entire Linux enviroment is affected by it. And it's actually a big problem.

I'm aware of this, but binary and/or compiler compatibility come at a price too. Take Windows for example, there is an even greater deal of bugs, quirks and outdated technologies that are carried from revision to revision for the sake of binary compatibility. If that's what matters to you, you are free to use Windows, it is the best OS in that respect.

View this comment - View article - View full comments

Quoting: Guest

Quoting: omer666About DXVK, it is now used in native Linux gaming, with great results.

That's not what I call native Linux client.
Translating the call will increase the system requirements considerable compared to a decent native implementation.

Still the large majority of Linux ports use an API translation layer (Valve uses ToGL and Feral have their own technology for this.)

About kernel compatibility, the only game I had trouble running recently is Enemy Territory Quake Wars. I honestly don't know how good Mesa support is in general, and I get your argument about compatibility, but it sounds more like a rant against Linux development model than a real discussion about graphic APIs and how they are handled in Linux.

View this comment - View article - View full comments

Quoting: GuestYou are assuming here again that the game was developed when Mesa was at some sort of use. Back in fglrx times Mesa was not usabled.
You are assuming that games developed during those times still have the people that worked at those engines alive. Sorry to inform you that some of them are dead.

I am not assuming anything. Of course it comes with a lot of inconvence for the end-user, what I am saying is that whether it's Mesa devs who are wrong is debatable.

About DXVK, it is now used in native Linux gaming, with great results. Also, Zink is used for native software as far as I know. This is not only about Wine gaming anymore, even if it is still DXVK's main use-case by far.

View this comment - View article - View full comments

Quoting: GuestEven now the mentality of Mesa devs is problematic because well they care only about academical tests and surprise surprise nobody in the gaming industry gives a coin on their engine following academical papers...
And you start to wonder what is the purpose of Mesa when almost nothing follows the academical papers...

From a pure engineering point of view, they are right: implementing quirks inside graphics drivers is not convenient and complicates maintenance, which is even more of a problem for an open source project. You take the example of Windows but even in that case, there are many workarounds in games depending on your GPU type, so you are looking at two moving targets

That's where Zink and DXVK enter the scene.
My understanding is that you can't make a non-standard implementation of Vulkan, so it has no workarounds in-driver. The translation layer, on the other end, can maintain all those quirks. To me, this is the best solution from a technical point of view: Mesa takes care of implementing the latest standards, and Zink and DXVK take care of maintaining compatibility.

View this comment - View article - View full comments