Slashdot Mirror
Valve Sponsors Work To Greatly Speed-Up Linux OpenGL Game Load Times
An anonymous reader writes "Valve Software has sponsored some interesting improvements developed by LunarG for the Mesa OpenGL library on Linux for deferred and threaded GLSL shader compilation. What these changes mean for users of the open-source Linux graphics drivers when running their favorite games is that OpenGL games now load a lot faster. As an example, the time from starting Dota 2 until the time actually being within the game is reduced by about 20 seconds on an Intel system. While Direct3D has offered similar functionality for a while, OpenGL has not, which has given it a bad reputation with regard to game load times until all shaders are compiled and cached — fortunately it's now addressed for OpenGL if using the Mesa Linux graphics drivers on a supported game."
Up until Steam, what linux games were there? Oh, that's right. Just the iD games.
Nice to see that OpenGL is being improved on Linux. I wonder, if somebody will implement caching of the compilation results next? The ccache does exactly this for C/C++, and it really helps in re-compilations of the same source. Of course this is a bit harder as it sounds, since one needs to verify the compiler and all related component versions before using cached result of a compilation.
OpenGL probably need to move to an IR for shaders. For thost that don't know, shaders are compiled by the driver today. Many games generate shaders with a combinatoric explosion which creates a lot of work for the driver. You can cache the result, which is often done, but you'll end up recompiling when the user change settings, etc.
The solution is off-line compilation to an IR, but of course everyone need to be aboard. The downside is that an IR spec will probably add 'DRM' considerations whereas today OpenGL shaders are shipped in source form.
This won't affect Tux Racer's FPS. This will affect the load time on DotA 2, as well as other games which compile many shaders during load time.
Your joke isn't funny because running Tux Racer faster than 997 FPS has been possible for ages, even without these optimizations.
Who are sponsoring Valve? And why are the sponsors working on speeding up OpenGL?
Off topic, I know, but English might possibly be the most ambiguous human language in the world.
Does an OpenGL shader go through a complex optimization process, though? *maybe* a cursory one, but no where near as complex as LLVM.
Of course it does. A lot of them go through exactly LLVM!
So Linux sucks because anyone can improve it in the areas where they feel it is needed? Yeah, that does suck. Booo, Linux.
Pretty good is actually pretty bad.
When someone asks me why I think you're an idiot, this is one of the posts I will show them, it's 2014 and you're still acting in a childish manner...
Lets hope OpenGL can seriously compete with DirectX now that it has Valve support.
Can someone say something about the development effort to develop for both OpenGL and DirectX?
Maybe Microsoft will start letting everyone use their newest version of DirectX.
I think the argument is that nobody does so for several years.
If nobody is willing to develop a certain feature, then maybe there isn't a real demand for it.
Pretty good is actually pretty bad.
except that no one does.
"anyone" sounds like a lot of people, but Linux isn't just for coder enthusiasts with the know-how to fix their own problems. If linux is going to really take off on the desktop those things simply need to be already taken care of. With microsoft floundering around with windows 8 and tablets taking off, if someone wanted to really get market share away from microsoft dumping money into Linux like valve is doing here is a good start. Especially if it can be done in such a way that major game studios can easily make their games multiplatform. Games are what keep a lot of dedicated enthusiasts of all ages away from Linux. So are things like photoshop or microsoft office, or etc. A lot of the core products that people need just don't work well or at all. You can carry on about alternatives, but people don't want alternatives for those kinds of things. The OS, which is mostly background to a lot of people is easy to persuade them on, you can make it look and feel like windows. but gimp will never feel and look like photoshop.
Well, there's no demand for this because there's a relatively convenient alternative. In this case, the alternative is Windows and DirectX. It doesn't really say a lot for Linux if this is what people are doing.
Drivers to be renamed "Black Mesa OpenGL Library"?
I doubt people are using Windows because of the deferred and threaded GLSL shader compilation. I think it has more to do with the fact games are barely available for Linux at all. And that also has little do with how shaders are precompiled I think.
This feature just shaves off a few seconds during load time. That's great of course, but by no means a killer feature that previously has been a real problem for anyone. That's why the feature is late to the party and it is a gaming company who comes up with the patch, as they want their games to load faster. Makes sense, right? In no way I see how this makes Linux look bad.
Pretty good is actually pretty bad.
How is it Linux fault that Microsoft doesn't provide Office or Adobe doesn't provide Photoshop for it?
Pretty good is actually pretty bad.
Lack of games is a factor, but the other factor is games just aren't as good. Load times is a factor in this. And while it may not seem important, 20 seconds is a lot! On consoles, load times are a reason to fail compliance testing.
For games devs, the choice of API to use really depends on platform targetted.
The Direct3D API isn't *quite* the same as the one used on the XBox consoles, but it's very close. That makes porting a much easier, cheaper prospect. I don't know what API Playstation games require.
So hurray to Valve for fixing this and hurray to Linux for letting them, right?
Pretty good is actually pretty bad.
And that also has little do with how shaders are precompiled I think.
As far as I know, you cannot precompile shaders anyway because the compiled code is hardware-dependent. The shader processors are different among architectures and manufacturers, and do not have a common baseline like "x86-64" to target, like we have on the CPU side.
I meant precompiling in the sense of compiling them during loading, so they can be used during gameplay.
Pretty good is actually pretty bad.
Well, there's no demand for this because there's a relatively convenient alternative. In this case, the alternative is Windows and DirectX. It doesn't really say a lot for Linux if this is what people are doing.
Yes, exactly right. 3D gaming isn't some half-dead community with no revenue stream on other platforms. Hell, other platforms were created for gaming due to demand (From Atari to PS4), which has been going on for decades.
In the meantime, the Linux community sat on the sidelines and assumed what everyone really wanted in any new distro...a new version of GNOME or KDE to keep other more "important" debates alive.
While I can understand an efficiency within demand, it's rather odd that Linux still looks at 3D gaming like it's a 20-megapixel camera in a cell phone, when we in fact have 20-megapixel cameras in cell phones these days...
Kinda, yeah. What we're seeing now is the breaking of the chicken-and-egg problem of gaming on Linux. Up until very recently, virtually no developers bothered developing games for Linux, because no-one does gaming in Linux. No-one ran Linux for gaming, because there were very few games for Linux (and the drivers were a pain).
Up until recently, Linux had merely taken over the world when it came to servers and mobile (Android). Now it's being given a real shot at gaming.
You sit around chatting to other real people about how much you hate one Slashdot poster? Enough so that you feel the need to collect evidence?
Something tells me you haven't GOT any real people to talk to. If you did, you might not be so sick in the head.
I think the lack of these applications on Linux has a lot more to do with politics and business strategy than Linux being a bad platform somehow for developing applications like Excel or Photoshop for.
It's not that these applications have some intrinsic connection with Windows either, as both of these products are available for Mac OS X.
Pretty good is actually pretty bad.
Actually the hardware support is quite good already. I agree with your other points though: Linux world is a mess with parts missing, lots of bugs, and lacking quality assurance.
Well, 10% is not that big of a deal if you look at frame rates or such. However, If you turn that into dollars by comparing how much you have to pay extra for a better video card or processor to get that additional 10% boost, well then the whole situation looks a bit different. Then again this is a bit of dumb way to look at it...
As I understand it, compiled shaders aren't very big, so precompiling for a few dozen chipsets isn't much of an issue storage-wise.
How many different chipsets are there to support?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
When I was working on this sort of thing a few years ago, we were experimenting with a RISC machine with a fairly deep pipeline for shader operations.
It worked pretty well, and wouldn't be surprised if the big boys used a similar idea but optimisation for these is very architecture dependent and can be an NP complete problem. Even register allocation can be quite slow and they'll have to deal with that.
...both have functionality for accessing (and saving) a compiled shader so that it can be loaded and used instantly on next run.
So that's what is taking so long when starting Dota. I was wondering what part of loading a game could max out a thread on the CPU.
As an example, the time from starting Dota 2 until the time actually being within the game is reduced by about 20 seconds on an Intel system.
A WTF comment if I ever saw one. One would prefer at least two numbers to know how good the improvement is, though a percentage would also be better. On my Intel system Dota2 takes about 15 seconds now. And what's with the pointless Intel name-drop anyway.
Caching seems like a better solution to me, but multithreaded compilation is also good. Well done Valve
It's not lack of quality assurance, it's hostility towards quality assurance. And with quality assurance I don't mean bugs (there are lots of them), I mean basic usability. I have been told they specifically won't implement certain basic functionality just to be different from MS. With that attitude is no wonder that Linux is only used by "cultists" that use it more as a sign of group identity than as an OS.
Your argument is immaterial, because a lot of BOFH-s and ThePointyHaired-s use Mac. Plus, they are in average willing to spend serious money for licenses.
Because linux isn't a cohesive platform. That's the problem. As I was googling around one of the staff at adobe mentioned last year that Linux lacked standardized APIs on a forum thread regarding photoshop on Linux.
There is a perception that Linux is a bit like the wild west and in this day and age when you have stable mature platforms like Mac and Windows available, that's risky for developers. Even for big companies.
The intrinsic connection they have is market share and having already been the platform for this programs for a long time. Linux needs to really step up and say "Hey we're ready look at us" but they haven't had that moment yet.
Ubuntu is a step in the right direction. If a company with real money can get behind it and drive it to some kind of consumer ready level like Windows or Mac is, enthusiasts can still sit there and fork and tweak and do as they like, but getting a real ready version there that gets people's attention and wants to make people use it and develop for it is what will drive Linux's success.
It might not be directly Linux's fault that Microsoft doesn't make office for Linux, but they just got office for IOS not that long ago. Who knows what kind of wrangling that took. But if I was someone like Canonical I'd see just how much money it would take to convince Microsoft to make it for linux and make that happen. I'd do the same with programs like Photoshop, and other major programs that have major user bases that are seen as core apps. Valve already seems like they're moving in the direction of taking care of games so I'd make sure I was meeting with them and getting everyone on the same page. They don't have to arrange all the programs. If they do a few core programs that reach a large percentage of the user base, the other programs will start to get ported to linux as user base picks up. For example if they paid to get photoshop and office ported and linux went from the low single digits its sitting around now on the desktop up to 20% or a little higher I think you'd see companies start to take notice and start to focus a little more on it.
OpenGL. Just like WiiU, Android, iOS, and every other platform that isn't Microsoft.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Im also hoping they deprecate the libraries in Team Fortress 2 that are patent encumbered before someone hauls them into a texas court. W have perfectly reasonable alternatives to S3TC.
Installation and posix portability are also on my wishlist but thats sort of offtopic and not likely to happen without a bit of ecosystem backlash..
Good people go to bed earlier.
But is is 'pure' openGL, or something with lots of propritary extensions?
I have been told they specifically won't implement certain basic functionality just to be different from MS. With that attitude is no wonder that Linux is only used by "cultists" that use it more as a sign of group identity than as an OS.
Yes, because anyone wanting to avoid getting sued by Microsoft for infringing their patents is clearly a "cultist".
Uhm.. no. It's fairly similar to OpenGL and is based on the same principles, but certainly not the same. You don't really want the same. You have no need for the level of abstraction OpenGL provides.
The smartphones use OpenGL ES which is actually a different API from OpenGL although it is a variant used fro embedded systems.
If nobody is willing to develop a certain feature, then maybe there isn't a real demand for it.
In the same way there was no demand for Interstate roads or the Internet.
It's not Linux's fault. It is, however, a legitimate reason why many people don't use it on the desktop, and simply stating that not the fault of Linux doesn't mean jack shit - the lack of suitable applications will still make it less desirable for many people as a desktop/workstation system if it ain't running the software they want.
Certain Linux users keep playing the victim, that the OS is perfectly fine and it's the manufacturers who don't support it. Be that as it may, an OS is only as useful as what you can run on it...
Because linux isn't a cohesive platform. That's the problem. As I was googling around one of the staff at adobe mentioned last year that Linux lacked standardized APIs on a forum thread regarding photoshop on Linux.
So how come Autodesk is able to ship Maya for Linux? Or MathWorks has no trouble releasing Matlab for Linux?
You're talking like it's impossible to create software for Linux. Clearly this is not the case, as there are numerous applications available for Linux and have been for years, in all sorts of forms and business models.
The lack of Photoshop and MS Office is not really because of any technical reason. The reality is that Adobe and Microsoft don't want their products available on Linux.
Pretty good is actually pretty bad.
>
On Mac, OpenGL wins 100% complete, hands-down. Unless you count boot-camp, which is really just Windows.
You can try to paint a different picture all you like - fact is that OpenGL is not only "the same" as DirectX when you're on Windows, but also runs in a ton of other places.
Don't forget iOS and Android. Both of those use OpenGL ES.
Yet we have interstate roads and the internet, just like we have threaded shader compilation on Linux now.
If someone wants to create a feature for Linux, one can. That is the freedom Linux provides. If nobody is willing to take on something, then apparently it isn't such an issue.
I really don't get why people are giving Linux so much hate for empowering it's user base in this way. If you have a complaint about Windows or Mac OS X, Microsoft and Apple tell you to go fuck yourself. But if you want Linux to have something it doesn't have already, you can just go ahead and build it.
I think that's cool.
Pretty good is actually pretty bad.
Because there's demand for it from paying customers (although I wouldn't be surprised if the vast, vast majority of MATLAB users for example were Windows users, but I digress).
Adobe has presumably made some calculations, used various source of information, and made a determination that porting Photoshop and the rest of their core applications to Linux will not be profitable. FFS they've already stopped porting Adobe Reader years ago and don't patch the main Flash plugin on Linux unless a big security vulnerability is exposed.
They just don't see Linux as being that important a market. Do you really think they'd deny themselves profit? Are you so arrogant you think YOU know better than Adobe at the market they make millions in?
Do not think for a minute that the big companies that don't support Linux haven't made a calculated decision not to bother with porting software to it. No-one knocks back an increased income, but if it costs more to support it than they'd see as profit, it's a net loss and bad for business.
I'm just saying if people want Photoshop on Linux, you should talk to Adobe, not Linus Torvalds or Mark Shuttleworth.
Pretty good is actually pretty bad.
I'm not the one saying Adobe should release Photoshop for Linux. I'm just saying the *only* reason why Photoshop isn't available for Linux is because Adobe doesn't want it to be on Linux. That may well be the result of some business calculation, or politics, or something personal or whatever, but certainly not because Linux is in some way not suitable for running an application like Photoshop.
Pretty good is actually pretty bad.
Your right because clearly starting up your little games faster should be top priority of any operating system.
Their claim is that it is is and that might be why they don't want it on Linux. Because it is less suitable, less easy, it will cost more to port it over and since they don't yet see a big market for users they won't do it.
It's chicken and the egg. The existence of other apps is immaterial. Other apps might be suited to Linux, they might be easy, cost effective to port and they might be targeting people who might otherwise already use linux.
However, if you get them to do it, the users will come and it will start to snowball. It needs that push to get going and that only comes with money.
So 20 seconds off the start of a game you'll probably play the next two hours. Duh!
Yes, Linux has not been the go-to platform for desktop gaming. MS has had quite a bit of control over that area for a good long while, and has been in a pretty good position to protect that spot (and other practices regarding their OS have assisted with this as well). The impetus for the change here is that MS is shifted towards a walled garden approach now, which has Valve concerned.
This is my signature. There are many like it, but this one is mine.
FFS they've already stopped porting Adobe Reader years ago and don't patch the main Flash plugin on Linux unless a big security vulnerability is exposed.
The PPAPI version of Adobe Flash plugin for Google Chrome under Linux is still being developed and is doing fine. The old NPAPI plugin will remain frozen in the 11.2.x.x tree and receive occasional security updates, as you correctly said.
Well it isn't a bad platform to develop for. It is just insane to spend money developing for a platform that _nobody uses_. And by nobody, I mean the meager 1% or less that usage statistics show. Even within that 1%, there are a rabid subset of "no COTS, no proprietary, only open" - so those are immediate "no sales". So while the platform is fine, the economics of the situation would show insanity in developing for it.
Your right because clearly starting up your little games faster should be top priority of any operating system.
Not any operating system, just one that has interactive users. When I turn on my computer I want to use it right now, boot time is dead time. When I click any application I want to use it right now, load time is dead time. If I click a button in the application I want a response right now, reaction time is dead time. If you're running a server, who really cares as it should be >99.99% up, use staggered boot and launch some huge backend processing service once it doesn't matter at all. But when it's my consumer device I hate fingertapping time, it's not that I really need those five seconds back but it's very, very annoying. I kind of accepted it when computers were slow as molasses, but I very rarely accept that I need to wait for my gigahertz quadcore CPU feeding off an SSD to do anything. YMMV, but I think there's more people in my camp than yours.
Live today, because you never know what tomorrow brings
Yes, there are some dickheads in charge of major Linux projects that refuse to do things users want. There are also dickheads in charge of major Microsoft proejct that refuse to do things users want. Same with Apple, Adobe, Oracle, and many other companies.
and no, it's not only used by cultists. It's used by smartphones, GPS, DVRs, servers, supercomputers, and other places. The desktop is more of an exception than a rule, but the desktop is the place where the OS is more visible.
This is my signature. There are many like it, but this one is mine.
Neither would answer you if you tried to talk to them, so people do what is reasonable and vote with their money.
That's probably true, things only really change when someone brings a lot of dollars to the table. That's what Mark Shuttleworth did with Ubuntu, Google did with Android and Valve is doing now with SteamOS.
But that's really what I was trying to say at the start of this thread: the fact anyone can step in and add to the platform is what I think is cool about Linux. So having a real impact in businessland may cost some money, but it's not like that's going to Linus Torvald's personal bank account. Linux is open for everyone and not charging a dime. So why are people giving it a hard time?
Pretty good is actually pretty bad.
Because being free isn't a pass on criticism. I'm not sure when that happened. Yes all the people who have devoted time and effort and money on Linux deserve credit for doing so. But for the end consumer there is no real difference between an OS you got for free and one you paid $100 for. They still need to work and they still need to do what you need. Otherwise free doesn't mean anything. In the end they're still providing a product regardless of the cost and the consumer is going to form an opinion on it and give feedback. It's simply just not there yet and the only thing that's really going to get it there, in my opinion, at this point is a huge infusion of cash in exactly the right direction.
You are an idiot. You are saying "one can" like it is as easy as baking a cake. I would love to replace windows with ubuntu or mint or something for all my gaming needs, but I wouldn't have the slightest idea on how to even start coding a feature for linux. This is some pretty specialized stuff. Sure you position it one way "Linux is empowering it's user base", where someone else sees it as "Linux doesn't give a fuck about anything.
Screw users. if they want something they can do it themselves.
Also, it isn't like windows is a walled garden like IOS, you can develop drivers, software, etc for it as well. Sure maybe you can't modify the kernel (easily), but at least Microsoft provides tons of tools to change windows behaviour.
You are smoking crack. The reason is because non-open drivers have had this implemented since word "go". That's what people wanted to use. Hence, the whole supply/demand thing kicking in. That someone is doing it in the open-source drivers means that they aren't getting the love they expected from the third party, and suddenly there is a business interest in having better support in the open driver.
To draw a parallel, would you use the default drivers that come "out of box" on a fresh install on Microsoft Windows whatever, or would you actually go to the vendor's website and download their specific drivers? I think we're done here.
Because linux isn't a cohesive DESKTOP platform. That's the problem. As I was googling around one of the staff at adobe mentioned last year that Linux lacked standardized APIs on a forum thread regarding photoshop on Linux.
There is a perception that Linux is a bit like the wild west and in this day and age when you have stable mature platforms like Mac and Windows available, that's risky for developers. Even for big companies.
Claiming that GNU/Linux is unstable and/or not mature as a platform feels like quite an ignorant claim. That is why I had to add the desktop part to your post. Yes, there is a proliferation of desktop environments and window managers for GNU/Linux and X (or whatever other alternatives are out there :) ), but that doesn't say much about Linux, the kernel. And if it was so risky for developers, how come Linux is so popular server side applications?
His point is theyre just now getting features that have been around on Windows for a while, which is a valid complaint.
"Anyone can improve it" holds a lot less water when we're talking about graphics subsystems-- how many people are legitimately qualified to work on that?
On a side note, isnt Mesa the crappy default driver thats usually replaced by the vendor's binary blob if you want decent performance? Or am I thinking of something else?
The compiled code isn't just dependent upon the chip. Simply changing a uniform variable or a texture parameter can cause the shader to be re-compiled.
This is what we call a "chicken and egg problem". Seems simpler to just say this than to try to explain how there are no games for linux because its graphics and gaming capabilities have historically been terrible, and theyve been terrible because noone games on linux and thus theres no incentive to develop them
If Linux wants to grab desktop market share it has to develop a killer app. Microsoft realized that early on and focused hard on areas that it suffered in; in the mid 90s it realized its printing subsystem was terrible and developed it, it realized that its gaming capabilities didnt exist so they made DirectX, etc etc.
Is not impossible, but is very hard. Programming for linux is a eternally moving target. When you think you finally finished developing your application, someone changes something fundamental to the system and you have to start all over again, and when you complete the necessary changes in the system, someone change it again. It is not feasible to stay indefinitely changing your application to run on a system that does not have a stable API.
Religion: The greatest weapon of mass destruction of all time
> Lack of games is a factor, but the other factor is games just aren't as good.
That's just nonsense. It's the same games running with the same levels of performance (or better). This is how it is now and how it was even back in the dark ages with Loki.
Being able to flee from an Intel GPU is far more relevant than what OS you're running.
A Pirate and a Puritan look the same on a balance sheet.
Perhaps because ever-shifting APIs and too many distros make it too hard.
> That's the problem. As I was googling around one of the staff at adobe mentioned last year that Linux lacked standardized APIs on a forum thread regarding photoshop on Linux.
Yes. And that post included obvious bullshit. While the "professionals" were bitching and moaning, the "hobbyists" in the community were simply taking care of business and doing all of the things that the "professionals" at Adobe want to declare is impossible.
Whiners that don't want to be bothered can always find excuses to distract from their own failings.
WinDOS has never been a particularly platform for anyone. It gained an advantage and then dominance because of the self-perpetuating notion that everyone used it. Thus it's easier to make a buck.
"Being better" never helped any alternative including MacOS. It's always about who has the biggest herd and thus the largest market.
A Pirate and a Puritan look the same on a balance sheet.
I dunno. I see Windows games running on Windows taking forever to load. I see games on other platforms also taking forever to load. It's kind of hard to see the reason to get excited here. The usual propaganda that Windows is some shang-gri-la ideal just doesn't wash here.
A Pirate and a Puritan look the same on a balance sheet.
Yes.
There are quite a few complaints about DotA load times. When you're waiting a couple of minutes for a game to start, you're getting to Commodore 64 levels. Shader compiling isn't the whole story, but it's a significant factor.
Linux is in a developer darkage...
While a valid excuse, that's another reason why Linux is still "not there" yet. The fact that there were only a couple legit games for it proves it's still in it's fetal stages of becoming a consumer OS. It's got a long way to go. Valve was a huge shot in the arm though. They are the best thing to happen to Linux in awhile.
"As I was googling around one of the staff at adobe mentioned last year that Linux lacked standardized APIs on a forum thread regarding photoshop on Linux."
And that is a reliable source of information? Most likely Adobe devs don't want to support yet another GUI toolkit/API. Linux has different GUI tool kits available, the most common being QT and GTK, both of which support Windows and MacOS in addition to the usual open source suspects. Hell, if you write a GUI Linux app that uses a cross platform tool kit and don't rely on X libs, you can in theory recompile them against Wayland or Mir without any changes.
There are plenty of standards in Linux as far as API's are concerned. The only real problem (which is not a bug but a feature, I'll explain below) is binary compatibility across distros as there are different library versions shipped with different releases and paths to said libraries can vary slightly. Package management (rpm, apt, etc) also varies from distro to distro. This is why you don't see universal binaries which can be a hassle for developers of proprietary software. OSX uses universal binaries which sort of solves this problem. Universal binaries were proposed back in 2009 for Linux but the patches were rejected by the LKML crowd.
Just look at the OpenSSL heartbleed fiasco as a great example for that reasoning. They had all sorts of legacy code and custom memory handling to support obsolete systems such as Windows 3.1x and pre MacOS X (8/9). Sure they were an open source project but they fell into the backwards compatibility trap. This is the same reason Windows became a security mess. Many of its libraries and API's have backwards compatibility with software from nearly 20 years ago (Windows 95). But it is what also makes it a convenient development platform. You could in theory release a binary in 2000 and it should still work in 2014. You can write Windows code using strait C by calling the win32 API's and you can build that code for 95/98/NT/Me/2k/XP/7/8. There is also backward compatibility for older .net, c++ libs, DirectX, etc. This is perfect for users of older software who: don't need to upgrade, can't afford to upgrade, need to support older systems or the developer is out of business and the user depend on that software. Same goes for games. In many cases older windows games run just fine. Though Windows does not support 100% backwards compatibility, it certainly has a lot of it.
Whereas in open source land, backwards compatibility is not expected between versions. With Linux and open source in general, if a library is changed and a feature deprecated or removed, you tweak your source and rebuild. Though not everyone wants to or can for that matter, build or tweak source. So distros provide binary packages of common software and libraries for the sake of being user friendly. But that hampers closed source developers who want to protect their IP. I don't blame them but they have to adjust to the ever evolving world of open source libraries and API's. This is the same reason video card drivers on Linux are a huge headache. Instead of providing binary drivers they have to provide a whole obfuscated build environment to pull in the necessary libs and kernel headers for your distro and compile the driver against them. If the video card developers released the source, distros could provide drivers downstream tailored for their distro.
Its a totally different eco system for the game devs and they have to adjust. But its not a huge uphill battle. Crytek ported the Cryengine to Linux and Unreal 4, which is becoming a very easy to use game engine on par with Unity, runs on Linux. So we have major engines now available for Linux and I can't help but think this is all thanks to Valve. Thanks Valve!
As far as I know, you cannot precompile shaders anyway because the compiled code is hardware-dependent. The shader processors are different among architectures and manufacturers, and do not have a common baseline like "x86-64" to target, like we have on the CPU side.
Why? Surely the shaders remain stored in the video card's memory and don't directly interact with the host OS.
We do have common baselines of GLSL and HLSL, but those are converted into hardware specific instructions on the card itself.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Seems simpler to just say this than to try to explain how there are no games for linux because its graphics and gaming capabilities have historically been terrible
But they haven't been that terrible. Linux has had a rather good OpenGL support for a long time. Sound has mostly worked well enough, especially if you tapped directly to OSS or ALSA. After that, what else do you need than input support and possibly networking. All the ingredients for a game are there. During the last 10-15 years, I do not see any terrible endurances if you really wanted to make a game for Linux.
I say it's been more about the lack of interest (it's been a small market after all) rather than technical capabilities.
Linux(purtians) is hostile to developers...they(those people) moved to microsoft(Quaker land)...
They never declared it impossible. They said it was a riskier more uncertain market with no return potential. There is a difference.
You are an idiot. You are saying "one can" like it is as easy as baking a cake. I would love to replace windows with ubuntu or mint or something for all my gaming needs, but I wouldn't have the slightest idea on how to even start coding a feature for linux. This is some pretty specialized stuff.
This is very true. We need to get out of the mentality that open source automatically means that everybody can contribute to projects just like that. One cannot usually craft even a simple 10-line patch if they do not understand the architecture of the project, and something like that can take months to grasp. Oh, and then people maybe do not even want your patch or you find that your commit tags were wrong or your MUA screwed up something and all that circus. :D
It's like saying that "everybody can contribute to the research of cosmology, the current research and complex mathematical equations are freely available".
Actually, for DOTA2 the load times were a pretty big issue for me. I could join the same games as the windows folk, but loading assets took a noticeably longer time, to the point where sometimes I'd get dropped from the game at start and then have to reconnect. This would only apply to the first game (afterwards I'd assume assets are cached). Ironically, performance on Linux once assets loaded is actually better, but this caused some pretty annoying issues.
If I am not mistaken, Win8 - and WinPhone8 - support OpenGL as the Direct3D/etc APIs were too power hungry....
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
So the problem is exactly those hardware specific instructions. We cannot ship a game with precompiled shaders to hundreds of different chip families by NVIDIA, AMD, and Intel.
What we could do however, is to cache the compiled shaders locally and recompile them only if a hardware change is detected.
Maybe those companies think that Linux is somehow a bad platform to develop to. In that case it would be Linux's fault.
Microsoft is very reluctant to develop for anything non-Microsoft as that would mean people wouldn't need Windows; so anything that does not drive business to the entire Microsoft eco-system typically gets ignored by Microsoft. They're finally getting around to releasing Office for Android in some form - even then, it's not as functional as what they have on Windows.
As to Adobe...They could easy port it to Linux if they desired. My guess is they don't get enough requests because the majority of people they target are either Mac people or locked into Corporate environments where Windows or Mac are the only options. So, go bug them about delivering it on Linux and get a lot of others to do so as well. Make them see a market for it and you'll probably get it.
Same goes for AutoDesk (which I know uses Qt as a base for their development) and any other proprietary company. Valve getting behind Debian like this for SteamOS is probably going to start a good push for other companies to do the same kind of thing - especially if they get out an evangelize how easy/difficult it has been for them to do so.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
FWIW, the Nvidia proprietary drivers have had a shader cache on Linux since the 290.03 release in late 2011 (search for GLShaderDiskCache). It probably helps Mass Effect 2 under Wine somewhat (here's a bug report from before the cache was added to the driver: http://bugs.winehq.org/show_bu... )
Linux doesn't want anything, it's an operating system.
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
It is exactly this type of arrogance and handwaving that prevents Linux from being a viable desktop operating system. That is why it has been relegated to being just a toy OS for telephones.
It certainly doesn't help that development and distribution on Linux sucks ass, so porting to Linux is a huge time-sink compared to porting to OS X. Unless you pick a specific distro and *only* support that, in which case the Linux fans who yesterday were begging you to port the software are now bitching that you built it for the "wrong" distro.
Then your support costs run up the roof, because even in the "correct" distro people can install the "wrong" windowing system or sound subsystem or what-not, which becomes a support nightmare. So you pay more to port, then you pay more to support the port, then...
when you're done, nobody buys the thing anyway because "information wants to be free" and, shockingly, a community based primarily around a free-of-cost OS and making their own free clones of commercial products doesn't like paying money for things.
This stalemate isn't likely to change unless there is a major cultural shift in the Linux community.
Comment of the year
You're a known zealot, liar, and troll, so it's hard to believe you've seen much gaming action on Windows at all. Coincidently, the Source engine Valve is kludging along with is particularly slow compared to other modern engines like Platinum, Unreal 4.1, Visceral, ect. About the only engine slower to load than source is CryEngine, but it delivers for more.
Programming in OpenGL ES is still very similar to programming in normal OpenGL.
The DirectX texture format was based on S3TC, which is where the linux requirement for S3TC support came from. Everybody baked their textures into DDX(?) files and it was less of a hassle to just have linux support it than to either include raw or rebaked assets for OGL platforms (I'm including OSX here, since the two major porting platforms when this was going on were OS9/OSX and to a lesser degree Linux for Loki, Hyperion, VV, and the various other smaller companies who put out the effort.) As a result linux ended up supporting S3TC, albeit infringingly, and various games/ports/whatever else were set back by years/indefinitely.
A 10 year old engine that's at the end of it's lifecycle is slower than engines that aren't? Good to know.
There is no memory shortage. yes I have heard of XFCE. Go away.
And mostly it's been ignored on Linux because it was nearly impossible to get specs on how to program the video cards. On Windows most everything went with DirectX so that there wasn't even the portability that you might get via OpenGL (ie, there are very few realtime 3D games on macs either, except via Wine for older games).
OpenGL works... if you use proprietary drivers, which aren't installed by default and most OSS zealots users won't install them and end user distros don't install them automatically. But especially the nVidia proprietary driver is really good and the only sane OpenGL implementation on Linux that I know. Mesa typically is sort-of OpenGL compatible but leaves out features in unexpected places - either because they are not done yet or more annoyingly because they don't want them to be in there for political reasons. At times Mesa even goes as far as claiming that something works OK when in reality it is faked in a way that is totally broken. I still remember the night shifts I've had because of that one...
http://www.moonlight3d.eu/
Ubuntu has it's own problems though, it's more of a breakaway from whatever standards Linux was getting. The real problem is not so much the APIs, but the package management. Professional products want to provide a bundling that works with a package manager, but the one thing that varies the most between distributions is package management. So some commercial products in the past have only provided RedHat support for example (you can use it elsewhere but you're on your own trying to figure out how, and the casual user is going to be ignorant of how to get that done).
That's one of the funny things about OSS: when it comes to graphics, I perceive open source software to be mostly lagging behind by a couple of years at least. - whether it's 2d image manipulation, 3d modelling, offline rendering or real-time rendering. Somehow these topics don't get that much attention from the OSS community. Is it because so many hackers think that the purpose of X11 is to render more than one terminal window at once and the purpose of the window manager is to keep them arranged? Who needs window decorations with mouse buttons when you can do your window management with obscure keyboard shortcuts? People who work this way can often do awesome things with shells and programming languages, but at least 9 of 10 of them don't seem to care for graphics in any way. Those that remain are not enough to put the manpower to build decent OSS graphics software.
http://www.moonlight3d.eu/
Certainly Linux has been catching up lately in graphics, which was always one of the weakest points. What started the catch up is a de-facto rewrite of the DRI/DRM/Mesa, started with Intel's help, while AMD followed (while Nvidia is missing out, they still provide a decent proprietary driver). Now we even have Mesa providing a few OpenGL 4.X bits, which was not on a horizon just a few years ago. While Android didn't have direct influence on the desktop graphics stack of Linux, it's meteoric rise did establish awareness of the platform and thus many people began 'tinkering' with it, while also many companies took Linux support more seriously. Valve is one of them. Alhough their shift to Linux was mainly influenced by MS move to Metro (which more or less failed to take off), it seems they remain dedicated to Linux, continuing to finance the necessary manpower to fix various problems that were not deemed important for a platform without serious gaming - but are important for what Valve can bring to the table. If they want to get their console out, they need to do it with Linux kernel and surrounding ecosystem, and along the way invest couple tenths of million $$ to improve whatever needs work. For sure, MS won't give them unlocked platform.
Windows has had OpenGL since at least Windows 95. Most drivers include it. Games are just easier to write under DirectX, since DirectX is not meant as a general purpose rendering platform, but openGL is.
It's because good graphics developers are a finite resource.
With Linux and open source in general, if a library is changed and a feature deprecated or removed, you tweak your source and rebuild. Though not everyone wants to or can for that matter, build or tweak source. So distros provide binary packages of common software and libraries for the sake of being user friendly. But that hampers closed source developers who want to protect their IP. I don't blame them but they have to adjust to the ever evolving world of open source libraries and API's. This is the same reason video card drivers on Linux are a huge headache. Instead of providing binary drivers they have to provide a whole obfuscated build environment to pull in the necessary libs and kernel headers for your distro and compile the driver against them. If the video card developers released the source, distros could provide drivers downstream tailored for their distro.
Its a totally different eco system for the game devs and they have to adjust.
Yep, you nailed some of the problems on Linux, which largely come from different philosophies about backward compatibility. Open source means that you can simply recompile at any time, so binary compatibility is deemed less important. On the other hand, Windows has gone through unbelievable efforts to maintain binary compatibility with previous versions.
However, I'd take slight issue with your last line, indicating the "game devs have to adjust". As a game dev, I'm sort of wondering how I'm supposed to "adjust", exactly?
The game development tools, documentation, and source examples for Windows are superior to those I could find for Linux. Linux has a 1% market share among likely gamers (according to the Steam hardware/software survey), and that 1% is splintered across dozens of distros, many of which have compatibility issues with each other. And of course, the Linux platform and development team itself tends to be at best agnostic and at worst outright hostile to closed-source commercial application. All of this can add up to create a lot of development and support overhead for a platform with already tiny profit margins.
Honestly, is anyone really surprised that game developers look at Linux and say "no thank you"?
Please, don't get me wrong. I'd love to support Linux, but damn, you're asking a lot for a 1% market share. I'm planning a Mac port after the initial Windows version of my game is released, and a Linux port may *hopefully* come after that. I have to prioritize according to market share, since I'll be relying on the revenue of the first game to continue development of the other platforms.
I'm not going to suggest that Linux will or even should change their culture, which is and always has been based around free and open source. But I think it's probably best to be realistic about what tradeoffs the platform is making with those priorities. Some of the major issues can be worked around. For instance, most commercial Linux programs (like games) statically link all their libraries, and so avoid weird platform-specific library compatibility issues. And fortunately, most Linux distros use one of a few standardized distribution package formats, so you can at least hit the majority of distros, or perhaps just pick the most popular distros to target and still cover most of the market.
But really, saying that "devs must adjust"? Or what? Or they'll simply not support Linux, like they've always done. How does that hurt anyone other than Linux supporters and enthusiasts?
Irony: Agile development has too much intertia to be abandoned now.
Could it also be because mobile hardware doesn't have any D3D support?
You can easily kill performance by doing stupid things, like uploading textures in formats the driver doesn't like that much (that one actually surprised me a lot, but it can matter). Or like loading the data in an order that keeps the disk seeking when it could instead be reading. The later is something that gets optimized for a lot on consoles where the optical disk seek times are a nightmare.
http://www.moonlight3d.eu/
Shaders run on the GPU with full DMA access. Do you really want a binary not created by the drivers(compiler) to be running with ring0 access to all of your hardware?
Yes it is. But OpenGL ES is not OpenGL. There are features in OpenGL ES that aren't in OpenGL, and features that are available in OpenGL that aren't in OpenGL ES. Similarly the OpenGL ES shader language doesn't support everything that OpenGL ES does.
And therein lies the fundamental problem with Linux: "If you can't code, then you can just fuck off"
No wonder that after 20 years, Linux's desktop share is still dismal.
you would potentially need to precompile for every chipset, driver version, and opengl version combination. its just a lot easier to do it for one. you could cache them between runs as well, as long as the video card, the driver, libopengl, and the os has not changed.
While mostly true of OpenGL ES 1.x, 2.0 and above is OpenGL 3/4 without legacy pipeline support and reduced lower bounds on available precision.
OpenGL ES 1.x was very similar to native OpenGL, but removed a large amount of legacy cruft and support for features not available on mobile GPUs.
Uh, no. I simply meant keeping cached copies of the compiled shaders on that particular computer. Shaders would still be uploaded and run normally on the GPU.
While you _can_ use OpenGL on all of those platforms, you usually only get the best performance using proprietary graphics APIs on some of them.
Seriously? I am an idiot for not knowing how to code for linux? I guess that makes you an idiot from not knowing how to code a missile guidance system for the DOD, or not knowing how to build your own CPU from scratch.
If I were complaining about missile guidance systems or CPU building you might have had a point. But to answer your question, no you're not an idiot for not knowing how to add to the Linux code base. I didn't say that and I didn't imply that, the only one calling names is you. I just find it ironic that you feel you are in a position to say other people are idiots while showing you do not have any knowledge or skills on the subject at hand yourself.
Pretty good is actually pretty bad.
"Anyone can improve it" holds a lot less water when we're talking about graphics subsystems-- how many people are legitimately qualified to work on that?
Well apparently Valve found some, didn't they?
Pretty good is actually pretty bad.
Just wrap the damn thing up as a KVM imgage or a FatELF. There are also package managers that use namespaces to isolate things so you can have multiple versions of libraries running, and won't lost anything a package declares as a hard dependency. The tech is there to make it easy, but not many people who understand the distro model really don't want to go that way because of the huge maintainance burdena nd security risk that it will put on distro developers. Linux is supposed to be like legos, and if you want to jam an amorphous BLOb in there, it really should be done with consideration and forethought. I think the solution is to push devs towards stable cross-platfrom API's where possible (OpenGL, SDL, OpenAL) and to push for standards where there aren't any yes (physics, game lobby etc.) Or where you can't avoid rapid change to use versioned API's. Wayland should be much friendlier in this repect than X.
Linux is right in not trying to nail down everying, but some things have been nailed down very well, see the Linux Standard Base which has minor revisions evey 1-2 years and a major every 4-5 years. (Minor revisions are foward compatible with any prior minors of the same major series). So if you write you program for LSB 4.0 and only depend on LSB 4.0, you should be able to support 4.1, 4.2 and 4.3 with minimal hassle.
So I agree it's not something every indie dev could do on thier own, but a large company should be able to afford a quality linux guy that can put the proper thought into it and get something that works on 95% of the current distros.
You should at least try for fowards compatibility though, and if you fail at that, at least fail as loudly as possible. Slightly different library paths isnt' a big deal as theres the LD_PATH variable and the like. What's sometimes annoying is slightly different library names which forces the user to generate symlinks. Package management for games isn't that important, as most of the time you are letting steam or desura manage it for you, or are otherwise installing it into your home directory with the mojo installer or shell script.
Mesa is actually specific to the intel DRM driver. Noveou and radeon drm drivers rely on gallium. If you have mesa and your graphics is the intel integrated, then what you run is Mesa, and is performance comparable to the closed windows driver.
https://wiki.linuxfoundation.org/en/Packaging/Wiki
There's been some thought put into it. .rpm of the LSB to to it's XML representation. Add in the ability to interact with more package managers (not just yum and apt), and use containers rather than directores to install packages onto.
I think expanding the zeroinstall intrastructure as the best bet. Add in the ability to conver the LSB-limited
People who get a modern OS for free are not going to pay for Office or Photoshop, they're going to use Gimp and LibreOffice. Only suckers who are convinced that free = worthless pay for them. Or have the boss pay for them. So, it wouldn't pay MS to make an Office for Linux. And if they did, it would mean Linus won, as he said.
This completely bypasses the concept of research and innovation.
Right, because all any consumer cares about is games. Get a life, dipweed.
Natural Selection 2 loads like a drunken molasses-covered sloth with cement blocks on its feet even on Windows.
* Sound was a literal nightmare (given how many sleepless nights I spent trying to fix it) when they switched from OSS / ALSA to PulseAudio.
* Graphics is a crapshoot: if you have nVidia it can be OK if you perform the right incantation, if you have Intel you dont need to fuss with it but its not terribly performant, and if you have ATI/AMD you're out of luck.
* Gaming mouse support (7+ button support) historically required dark magic performed on the xorg.conf file, and/or the download of various utilities to properly configure it.
* Ventrilo (still quite popular) support requires straight up voodoo with Wine and ripped Windows DLLs (for the codecs); Skype may or may not work but (IIRC) hasnt been updated in about 3 centuries, and that all relies on you having done the right dance around pulseaudio to get mic input working.
At least networking just works, generally.
W have perfectly reasonable alternatives to S3TC.
I thought S3TC used the same concept as Apple Video (RPZA), which shipped as part of QuickTime 1.0 in 1991. Each 4x4 pixel block has two 15- or 16-bit colors and an array of sixteen 2-bit coefficients as to how these colors are mixed to produce the sixteen pixels in the block. What's the inventive step from RPZA to S3TC?
At least in 2D image manipulation, part of the reason that free software appears to lag by 20 years is that that's the duration of a patent.
If someone wants to create a feature for Linux, one can.
Not unless one owns the rights to the relevant patents and trade secrets. And GPUs are full of those.
Does this PPAPI plug-in work in other Chromium-based browsers, or only in Google Chrome?
Some people have said that you can cram it inside Chromium, but that it is a royal pain in the ass to do.
lots and lots and lots of proprietary extensions.
It's pretty common when you have a specific piece of hardware you want to have last for X years and you KNOW will not change during that time to work towards getting a bit more out of it. This will include a lot of tweaks and changes that only work on that hardware.
"There are plenty of standards in Linux as far as API's are concerned."
I don't think you know what standard really means.