10 Reasons Linux Gamers Might Want to Pass On the NVIDIA RTX Series

No I'm not, you are. You have no idea as to the layers involved in an operating system. Userspace does not communicate directly with the HAL.

It's a translation layer! under Windows the exact same translation takes place, just with the NT kernel as opposed to the Linux kernel.

Who the hell stated they did!

I can't handle this, you are hiding a complete lack of knowledge behind arrogance and it's beyond frustrating. You think that because you own expensive toys it makes you some form of expert, the problem is you don't understand any more than the manual feeds you.

This back and forth rubbish is unhealthy, think what you want, at least it'll make perfect sense in your own little world and to those that exist on your level of understanding.

 

Good fucking lord. That's exactly what the hell I've been saying. And after 25 years Wine still isn't bullet proof, far from it.

So why do you bring up the subject all of the time. You're no more representative of the typical PC gamer than me.

​

The niche Linux gamer preaching about what exactly?

You like Linux and that's fine. It sucks for gaming overall for tons of different reasons. People like you bash Windows for a living and then when it's convenient it's super awesome that Linux can run a little more Windows software.

 

whatever. then you should have said exactly that. You may have meant that, but it didn't read like that to me.

discussion over. all that over a meme, Jesus.

 

I'm pretty sure its much less than the .59% of linux steam users according to the survey

 

Mazzspeed, where did you come up with this? "I don't believe so, it's obvious that awareness of Linux is growing and Steam statistics are fairly useless at determining overall user numbers. However, my point was that in the beginning Windows was a far worse gaming platform than Linux is now and Gabe turned that all around - Microsoft couldn't have given the slightest crap about the situation at the time and I don't know whether they even care about it now considering Windows is installed on most OEM devices by default."

I have been gaming for at least the last 3 decades and I had no issues gaming on Windows from 95 on up. Gabe was not the savior of PC gaming but, he did add quite a bit to it and fathered the digital download service. Prior to Steam, I had no issues gaming on my PC and there were a crap ton of games to choose from. Linux gaming has never been better than Windows gaming and only recently, at least in performance for some games, equaled the Windows versions.

 

By that logic....

Direct X is a translation layer.
The MS Visual C++ visual studio (insert year) redistributable is a translation software.
MS .NET framework is a translation software.
Not that many people are using it hopefully but the MS Visual basic redistributable... would also be a translation softtware I guess.
MS MSXML packages... I guess are translation software.

By your logic none of that stuff is really windows. Kill it all I guess.

Wine is no more a translation layer then any of that stuff is... seeing as all that stuff extends or bypasses standards win32 calls.

Don't confuse what wine is with what DXVK is. DXVK is a wrapper yes no one said other wise. But even that isn't doing any real heavy work... DX 11 and Vulkan are not all that different.

A DirectX shader = float4 color; uniform float4 position : POSITION; const float4 lightDirection = {0,0,1};

A Vulkan shader = void main() { gl_Position = vec4(positions[gl_VertexIndex], 0.0, 1.0);

Clearly they are very very different. (they are not) What the last year of DXVK development has been about is finding the best way to convert already compiled DX shader code to Vulkan. Some developers (programmers) go about the same task in slightly different ways using slightly different calls which can lead to slightly different visual results. The DXVK developer has done a good job of detecting slight differences and outputting the most efficient lowest level Vulkan representations. To be honest in some ways DXVK could end up being faster... as DX 11 isn't all that low level and the translation that gets used sometimes is actually faster here and there once converted to Vulkan. (so in other words once the DXVK build the shaders and caches them you may actually see performance gains even though its a "wrapper") That is why everyone got excited not that long ago when the DXVK developer implemented shader caching.

 

So what does Wine do? It sounds like you're saying that Win32 should just run under Linux as is. Bottom line, Wine translates Win32 in native Linux calls. Otherwise it would serve no purpose.

 

I feel like you're just spouting your party line even though it doesn't relate to what I said. You replied to a post where I stated I think Linux gaming has been superior to Mac gaming for years now, yet it still doesn't have as much marketshare. So uh, yeah, I don't understand how what you wrote connects to any of that.

Gabe made DirectX? And no, Gabe didn't make the PC into a gaming platform, shareware companies did that. But DirectX certainly made WINDOWS into a gaming platform.

By roughly what year are you thinking? You say almost inevitable, yet here we are in 2018 and Macs have over 4x the marketshare as Linux machines in gaming. Again, I'd argue Linux is ALREADY superior to Macs for gaming prior to Steam Play, but hasn't made much of a dent in marketshare. If you asked me to choose between a Mac and Linux for gaming, I'd take the Linux machine every time. The fact that it's still so low says to me that marketing dollars matter and I'm not seeing an obvious path to Linux taking over. If there was one, I would expect Linux to have eclipsed Mac by now. Again, would love to be wrong though.

 

haha you still really don't get it.

Yes wine IS win32.

No translation.

Win32... Is nothing but a collection of programming libraries. Its a bunch of .dll files that a software programmer can call.

https://en.wikipedia.org/wiki/Windows_API
Actually read this....
If a software programmer wants to use say create a basic OK and Cancel buttons on a windows UI pop up window... they have to define the use of comctl32.dll in their software. Its a library that contains all the programming MS has done to make that work. Once it is defined they can make a "_windowsAPI_Button" call in their C code. (I have no idea what the actual flag calls are I don't write windows code)
Now their software will well the windows user space scheduler when it makes those calls... to load the relevant code from comctl32.dll

Now MS does not release the code for comctl32.dll or any of the other Windows API Libraries.

All they release is documents that detail for programmers how to call their code. So they don't release the code for comctl32.dll but they release a list of all the programming flags and their variable options so programmers can use them. There is plenty of documentation.

So what wine is... is a recreation of all those closed source windows api libraries. The wine developers took all that documentation and said ok when a piece of "windows" software defines the use of comctl32.dll... these are all the possible bits of code they can call... a bit to make a button, a bit to make a window, a bit to map integer / float / boolean expressions ect ect ect.

They reverse engineered the windows api libraries from the MS documentation... and created their own version of comctl32.dll and all the other libraries that make up the API.

When windows uses the windows API... the software using it isn't directly accessing hardware or anything, its running that compiled software in windows user space, and windows just like Linux has a software scheduler that provides the software hardware resources.

 

Honestly, going by what you wrote here, it does sound like software emulation (of software). But, because it's software that is running on the same hardware and compiled using the same tools, the overhead is basically nill. I guess you could say, the emulator translator is gcc.

 

You guys will argue with a stop sign. Here is the basic definition of Wine from none other than https://www.winehq.org/

If this is wrong you need to contact the Wine folks.

 

Which sorta contradicts what you've said earlier in the thread heatlesssun. But feel free to contact wine devs and set them straight.

Edit: nvm , must've been thinking of someone else. This argument has been going on far too long.

 

I said that Wine is a translation layer which comes from multiple sources. Some are simply making this WAY harder than it is. Wine provides a Win32 runtime for Win32 apps where code is executed under Linux via translation of Win32 calls into native Linux. At a high level that's all Wine is. What's so damned hard about excepting the explanation from the people that develop Wine?

 

Yeah, I could have sworn I saw you say wine is an emulator or emulates windows somewhere, but it must've been someone else. See edit above.

 

Again some hang up on a word, emulation. Yes, Wine does emulate Win32 under Linux, it's the whole point of Wine. That's just what the word "emulation" means:

emulation : reproduction of the function or action of a different computer, software system, etc.. Emulation does not imply a VM or any other technology, just mimicking somehow.

 

Right, but somehow I associated what (i thought) you said with the connotation that emulation somehow hurts performance, which isn't the case here. I imagine something someone else said had something to do with that.

 

I've not said a single thing about performance until now. Is there a performance hit using tech like Wine? It depends. As Wine is a translation layer the easier it is to map calls one to one between Win32 and native Linux, the less the hit will be. That's why so much promotion of Vulkan from Linux gaming types, those calls map one to one with no performance hit.

COM applications like DX don't map as easily thus more overhead.

 

Wine isn't translation... and you seem to not understand what POSTIX is. The portable operating system interface standard is nothing but a bunch of standards for maintaining compatability.

What the wine description is saying is.... our software is a API frame work that translates software written to use it (windows api using software) to Linux / Unix / BSD standards (postix) code. Which is why Wine works with Linux BSD Unix Mac ect.... the wine team hasn't had to completely rewrite wine to support mac or bsd or android. Because all those systems at a HAL level use the same standards. (something MS doesn't even do themselves which is why every windows version has a "compatability" mode)

You are not reading what they have on their site correctly.

You are conflating Wine and DXVK. DXVK is a a wrapper no doubt... it is converting DX calls to Vulkan calls. Yes. Wine isn't converting or translating nothing, at least not in anyway different from the way windows itself does it. If their is a bit of software code that runs slower or faster in wine its because the wine developers implementation of the software calls is either less or more efficient. If windows api was open source they would just use Microsofts code... its not open source so they have recreated all those calls. For the most part they are pretty much = cause there isn't some super secret ultra fast way to render a GUI radio button for instance.

If a game uses vulkan running wine or native isn't going to make much of any difference. This has been born out by a bunch of people testing. I'm not going to go and hunt youtube videos and the like cause I have had more then enough of this argument. lol The proof is out there though go and look... you can find examples of people running Vulkan games with Native linux versions and windows versions via wine and the performance difference isn't anything more then a couple FPS one way or the other.

 

Says right there on the damned Home Page of the Wine project that it IS TRANSLATION. At this point you're not arguing with me but the damned Wine project. Why don't you tell them to correct their page instead of ignoring what's right there on their site.

 

I am not debating that the word is on their site. I am saying you are TRANSLATING the English incorrectly.

To you translation means its doing something different then windows.

It isn't; windows is ALSO TRANSLATING windows software. The windows system scheduler isn't POSTIX compliant no (again POSTIX is just a standard) but it operates in the same way, TRANSLATING calls and assigning tasks to CPU resources. There is no simple way to bypass this core setup of any operating system. User space software only ever communicates with APIs which translate calls to lower level kernel and HAL systems.

Its why games in general don't have the best multi threading support... supporting such things means interacting with the OS scheduler more directly... in windows this is accomplished with UMS (user mode scheduling) calls to create and control specific threads, frankly there is a complexity there which is for he most part beyond most video game coders ability. Also to be frank video games won't see a ton of advantage over a handful of cores... splitting work up into smaller parts doesn't make things faster and leads to lots of extra context switching and the like which is slower then just brute forcing the data on a single core.

Linux has the same types of tools to take more control from the scheduler (it even has alternate types of schedulers)... but for the most part software developers rarely take direct control of such things. I only mention it because it is one of the reasons Valve has spun Proton off of wine... they claim to have implemented better multi threading. Proton seems to deal with windowsapi scheduling a bit differently then wine proper.... frankly there is a real possibility that proton may be a tool they even introduce to windows at some point. lol (only half kidding... it is possible their windowsapi layer may well end up faster then Microsofts own)

 

Because it HAS TO! Wine emits native Linux calls, that's not done with Win32 apps running under Windows. Code running under Wine becomes NATIVE LINUX NOT NATIVE WINDOWS. You're making the simple and obvious WAY more complicated that it is.

 

No it doesn't have to.

You don't seem to understand how windows works.... here;

1) Software compiled as an EXE. (written mostly in C or C++) is run
2) Program calls windows API libraries... to create GUI items, to interact with sound, video ect.
3) those windows libraries. (win32) take the requrests from the software and send them to;
4) the windows system scheduler
5) the windows system scheduler decides which user software gets which processor ect... it has priority settings and the like. when it requires the os to perform functions i/o sound ect... it passes those calls on;
6) kernel level interfaces with the scheduler and HAL
7) HAL talks to your actual hardware. (drivers are designed to interface this level with the kernel... which then lets the widows scheduler know what functions it can perform based on the hardware installed.)

Now here is the way WINE works

1) Software compiled as an EXE. (written mostly in C or C++) is run
2) Program calls windows API libraries... to create GUI items, to interact with sound, video ect. (system has the wine versions of these .dll libraries installed)
3) those wine libraries. (win32) take the requrests from the software and send them to;
4) the Linux user space scheduler. These schedulers (there is more then one) are POSTIX compliant.
5) the scheduler decides which user software gets which processor ect... it has priority settings and the like. when it requires the os to perform functions i/o sound ect... it passes those calls on;
6) kernel level interfaces with the scheduler and HAL
7) HAL talks to your actual hardware. Linux kernel space is split into OS kernel space and HAL (driver) space.

You see the point... they work the Exact same way. The only difference is step 4... the Microsoft WindowsAPI backend knows the language to talk to Microsofts system scheduler. (which operates exactly like the Linux POSTIX system... it just doesn't have a nice open standard name like POSTIX) WINEs back end sends the calls out as POSTIX calls. Its not translating the calls... in the way your talking about. The wine libraries are never creating actual windows scheduler calls.

I hope you get it... something tells me your won't. There isn't any EXTRA translation going on. The "translation" to POSTIX... is no different then MS calling the windows scheduling system.

 

Wow, you've spent a lot of time talking about a lot irrelevant stuff when the answer is plainly obvious as stated by the Wine team. Programs that run under Wine become native Linux at runtime, clearly Wine is translating calls of Win32 apps into native Linux calls. Just like the Wine team states.

 

Exactly just like windows software becomes native at run time after the win32 libraries translate the calls. It seems like perhaps you finally have come around... there is no more translation with wine then there is with microsoft w32 libraries. Both translate software calls to the OS scheduler.

 

OK, lets make something really clear here. Under Windows, system DLL calls are translated to the HAL, software does not communicate directly with the HAL. In the same sense, under Wine software communicates with effectively reverse engineered system DLL's which are translated to the HAL - The process is identical under both systems, there is no additional layer under Wine translating Russian to English, there is no hardware being emulated at all as the hardware is identical under both systems. What Wine is doing 'is not' comparable to a VM.

It's obvious you are backpeddling here, give it a rest. It's obvious that initially you wrongfully assumed there was an additional layer of translation going on that wasn't present under Windows.

I don't bring up the subject, you do, in every thread related to the topic. You can't help it. You do not represent everyone, your usage of your PC does not represent everyone - Even on the Hard forums.

I'm not preaching anything, I simply know what I'm talking about, unlike yourself. You're the one that feels the need to sell Windows to everyone, I'm simply refuting your stupid argument.

Well that all depends on the individual and the type of gaming they prefer when considering what's important to them regarding an OS. For many Linux does not suck for gaming at all.

Porting is porting, titles are ported cross platform all the time and not always completely re compiled for the alternate platform - This also happens under Windows considering console ports. The platform the title was originally coded for is therefore irrelevant.

You are clutching at straws trying to substantiate your argument that Windows should be used for everything and it's not working.

Apple have been supported under Steam about twice as long as Linux and only has roughly 2000 more titles in the Steam catalog than Linux, obviously developers can see something we cannot considering Linux under Steam. Don't worry about Steam statistics, they're nothing more than an arbitrary percentage informing us of very little without accurate user numbers - For example, it's entirely possible for the percentage to drop while the actual user base numbers under Linux remain the same. The other thing you have to consider is the number of Linux users using Wine, since the advent of Steam Play/Proton it's obvious that Wine usage has not been contributing to Linux statistics, in fact they've been artificially inflating Windows statistics and there is a large number of Linux users using Wine. The other thing to consider regarding Linux is that SteamOS statistics are not measured and are not counted towards Linux statistics. Yes, Steam Machines may not have been popular, but participating in Linux circles it's obvious there are a number of users using SteamOS on their TV for the convenience factor.

When it comes to viable gaming platforms under Steam, Apple products are by far the least suitable devices. Linux is a relative newcomer to Steam and Linux has no marketing department and is not installed on devices by default in anything representing large numbers, give it time.

 

Sorry man, I'm going to have to disagree with you on this one.
I remember the 1990s like it was yesterday, and PC gaming was struggling for sure (before 1993 or so), but it wasn't Gabe Newell that fixed that, it was id Software and DOOM that made PC hardware a serious gaming platform (or at least brought the killer app to it), and a few years later it was Microsoft with Windows 95 (and to a lesser extent, NT 4.0).

Before Windows 95 was released and in the early 1990s, PC gaming was just as you described, and unless a computer had a large (4-8MB+) quantity of RAM, it was difficult to get games to run properly, or with decent performance, on top of an OS, being Windows 3.0, 3.1, or NT 3.51.
Gaming could also be done on other computer systems, like Apple systems, though those weren't really classified as PCs back then (they were running m68k and PowerPC CPUs, not x86), so PC gaming really was on Intel and AMD second-sourced systems, aka PCs, back then, as you said.

However, Half-Life 1 wasn't released until late 1998, and gaming was vastly on the rise years before that.
Windows 95 is really what made this feasible, with an easy to use GUI and streamlined setup for programs, not to mention the very beginnings of Direct3D/X, which was also released by Microsoft in 1995.

Before Windows 95 and Direct X, yes, you are totally correct - PC gaming was the wild west of OS command calls and random APIs being utilized.
But Microsoft, much as I may like or dislike it, did historically set the standard with Windows 95 and Direct X, and again, this was years before Gabe Newell and Valve released the original Half-Life.

Half-Life was definitely a paradigm shift in how gaming and fps games could be treated, especially for the time, and while it did have some groundbreaking ideas and concepts at the time, it was more of a vitamin boost for PC gaming than "the cure" if you will.
PC gaming had been very serious for years before Half-Life was released, and if anything, DOOM (1993) and Quake (1996) by id Software should really take the titles of that, certainly not Half-Life (1998) and Gabe Newell.

 

Except it wasn't, Microsoft didn't care as they didn't view gaming as serious usage of their OS. Gabe worked for MS at the time, it was Gabe that first started porting titles to Windows, it was Gabe that pushed MS to develop API's in order to make Windows viable as a gaming platform. No offense and respect, but do some research, it's all there.

 

Ah, now I see what you are getting at, and yes, I will agree with that!

 

I remember gaming in the Windows 3.1 days...Ugh!

 

Too much agreement for this thread.

A lot of stuff came together for MS gaming in that chunk of years. There really wasn't a viable alternate PC platform for game developers to support... so your both right between a handful of killer apps like IDs software. And people like Gabe MS entrenched themselves pretty good. There where others like Alex St. John one of the first DX engineers that became the "DX technology evangelist" for most of the 90s who played pretty important roles in making sure game developers didn't just use DOS.

 

Ironically enough, even before this thread started, I've been asking friends or their friends, all of whom do both console and PC gaming, and asked them what they use.
Most of them use Windows, a few of them used OS X (for convenience as they work out of that OS mainly), and only one used Linux, even part-time - me.

I just met another person the other day, and they are very serious gamers who apparently only game on Windows and have never used Linux before.
So, those Steam OS stats really aren't painting an untruthful picture of things.

Yes, PC gaming can certainly include and associate with OS X and Linux - it would be wrong to not automatically include them.
However, when most people think or talk about PC gaming, they think Intel and Windows - where the term "Wintel" basically came from starting in the 1990s.

Heck, even AMD hasn't really been associated with PC gaming since the mid-2000s and only again very recently - yes, obviously people have been gaming on AMD since the mid-2000s (not including consoles here) and that includes me as well - but to the average person, they seriously think Intel and Windows, and it surprises them if anything else is mentioned.
They aren't surprised because they are in denial, but because they normally don't think of PC gaming on OS X, Linux, or even AMD - I am informing them about it, and now a lot of them actually want to upgrade their next systems to AMD and even give Linux a try - I know, I'm just as surprised as you are!


To say to people who have only ever used Windows, "Yes, you can get Linux working with WINE and only a few of your AAA games are playable and, oh you run VR games? Only a small handful of those will work..."
See where I'm going with this?

The average gamer look at that, even an ambitious gamer willing to try new things, and will look at the (to them) headache of things they now have to learn and hopefully get working all to achieve basically a lesser version of what they already have running, and really kind of give up before they start.
Not everyone wants to run Windows, and for them, this tech and setup is perfect, and especially for those who switch between the two operating systems, be it for work or passion, and it is so cool to see this functionality becoming mainstream with lots of user and developer support.

That's not say it still doesn't have a long ways to go, though, and until the day the average gamer can look at Linux and naturally go "Nice, I can do that.", Windows is going to be the primary and solely known OS platform synonymous with PC gaming.

 

I'm sorry I didn't really read past this part.

Understand I am not attacking heatle for this AT all... but he is not representative of the majority. In anyway at all.

He is running 2 top of the line video cards which... is 1 more high end GPU then 98.5% of Steam users. (1080ti is used by 1.5% of steam users as of Aug according to Steam)
He is using not just a Vive... but also an Rift. So understand that he bought BOTH. (I also think he has mentioned having picked up a windows mixed reality set but I could be wrong on that) ... when it comes to VR, again according to steam the Rift is #1 with 0.35% of steam users owning one.

That does not make him anywhere even close to representative of the masses.

He likes to burn his money on gaming hardware... and all the power too him. I hope he gets lots of enjoyment out of it all when he isn't spending his time on the [H] forums.

Having said that when he argues that windows is the only option for my SIG RIG. Sure he is right... no one has said otherwise. But how many of us are playing Eeny, meeny, miny, moe before we decide which VR headset to dawn today... and how many of us buy two of the latest greatest GPU more then once a year for nothing but gaming ? According to steam only 1 in 100 of us even spring for one every few years.

If Linux shipped as an OEM option... a great majority of the masses could game on it and be quite happy. As it is a great number of people are gaming on chromebooks and android devices. I'm not saying that is = to PC gaming... just saying those people count. Myself I don't hold one type of game above all others. Masses care about games more then impressive hardware specs and ultra realistic graphics. Just look at the game sales charts this summer. Octopath traveler was the #1 title in terms of sales BY a mile Nintendo sold 1 million copies in less the a month between July and Aug... and its a 16bit throw back RPG. (Speaking of which I am so fighting the urge to go and pick up a switch for that game and BOTW... I have a feeling I'm going to cave soon)

 

I get that a Linux fan would think this. People who are more practical about it though aren't going to thrilled about having a gaming PC that can't play most PC games.

 

Ok, that makes more sense to me, and I stand corrected.

 

Coming from the perspective of an unnaturally Microsoft biased user, that doesn't really mean much I'm afraid.

 

After everything is said and done, that really is the bottom line.
However, Valve is making progress by using WINE, and I don't see how that is a bad thing.

 

What's being able to play whatever game a person wants have to do with Microsoft? Shadow of the Tomb Raider just came out today. Are you saying that everyone that would like to play that game on their PC is an unnaturally biased Microsoft user?

 

Indeed and the funny thing is for all the folks that blast me over Linux gaming, I said point blank that Valve HAD to do Steam Play or otherwise Linux PC gaming was going to become less than a rounding error. I'm not saying that Steam Play is a silver bullet or anything though at this time. We'll see where this is in five years or so. Just like we've been looking at Steam support for Linux the last five years. This shit doesn't move fast at all.

 

"I'm not biased, you're biased!"

You're arguing from the statistically vacant position that is the Linux desktop, for a statistically insignificant slice that is Linux gaming.

Valve's pushing, some developers are cooperating, and mostly, no one else cares.

Now, I care- but I have no interest in misrepresenting reality either. What I see is the level of understanding in terms of translation libraries needed to build software like WINE and DXVK increasing to the point that the OS simply no longer matters. Pull the code, compile, and game. Or whatever.

And this isn't important today, not really- what's important is that as we hit further process shrink difficulties, we'll have to rethink software and hardware in order to increase performance, and having all of the understanding needed to glue the existing frameworks together will allow us to do that more quickly.

 

Never question the Linux fanatics. They are magically superior to the windoww pc master race because they say so.