Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
reboot

Valve and Linux

Recommended Posts

And once again Maes and Graf Zahl derail a linux thread with the same old shit. Congratulations.

Share this post


Link to post

And once again the Linux community makes sure that they stay a fringe group. Congratulations.

Share this post


Link to post

Yes, you're the lone voice of reason because you dare to think that Valve can't do what these developers have managed quite well on their own: make their game work on Linux machines.

Share this post


Link to post
Bucket said:

Yes, you're the lone voice of reason because you dare to think that Valve can't do what these developers have managed quite well on their own: make their game work on Linux machines.


There's hope? Would this work on all Windowing systems and such? That would be something I'd love to see happen. a truly universal binary for linux.

Share this post


Link to post

Not really sure what the "hope" is for; the developers have simply taken the effort to port their games to the platform, and it doesn't necessarily have any greater kinds of pains than any other platform port (be it Windows, Mac OS, Xbox 360, whatever).

As for your "truly universal binary", try not to fudge up terminology so much -- I believe you mean a binary that runs across all the major distributions and runs well without issues, most of those games already run just fine as such (and there are shitty ports, still; blame those specific developers, not the platform). On the other hand, if you mean universal binary more in the lines of Mac OS: there was (is?) such an effort: FatELF. Linus thought it was nasty and it enver got into mainline Linux.

FWIW, Csonicgo, you managed to have valid points to an extent. I'd argue sound systems aren't really that big of an issue anymore but there's still a bit of work to be done on them.

Share this post


Link to post
chungy said:

Not really sure what the "hope" is for; the developers have simply taken the effort to port their games to the platform, and it doesn't necessarily have any greater kinds of pains than any other platform port (be it Windows, Mac OS, Xbox 360, whatever).

As for your "truly universal binary", try not to fudge up terminology so much -- I believe you mean a binary that runs across all the major distributions and runs well without issues, most of those games already run just fine as such (and there are shitty ports, still; blame those specific developers, not the platform). On the other hand, if you mean universal binary more in the lines of Mac OS: there was (is?) such an effort: FatELF. Linus thought it was nasty and it enver got into mainline Linux.

FWIW, Csonicgo, you managed to have valid points to an extent. I'd argue sound systems aren't really that big of an issue anymore but there's still a bit of work to be done on them.


As a music producer in the making (working with DAWs and such) the latency issues of Linux become very apparent. some are saying you need a "realtime" kernel to do Professional audio in Linux, and if that's true, that's a huge problem.

Share this post


Link to post

Yes, I can see that being a problem. Not being involved with professional-grade audio at all, I'm not aware of the issues there.

Share this post


Link to post
Bucket said:

Yes, you're the lone voice of reason because you dare to think that Valve can't do what these developers have managed quite well on their own: make their game work on Linux machines.

Are any of those titles really pushing the hardware, though? Sure, Valve's games aren't the most intensive PC games, but they had a ton of video driver related issues when they released the Mac versions, and even after numerous driver updates those versions still require higher specs than the Windows versions. I have a hard time believing any Linux ports will be any different.

So what do you get with a Linux version of Steam? Less games than Windows (and probably Mac OS) and worse performance than Windows. No real selling point for someone on the fence, but keep in mind I'm still pretty excited about this happening at all.

Share this post


Link to post

That doesn't really tell me much. How does it perform compared to the Windows version on those same specs? I checked the game's specs on Steam and they're...low. Much lower than TF2 (TF2's minimum Windows specs are a joke, so ignoring those) or L4D2, for example. The Mac specs are actually lower than the Windows specs, though.

Edit: Also, off-topic, RealPlayer on the desktop? On the Linux desktop? Has that player even been relevant in the past decade? Most Windows users wouldn't touch that garbage.

Share this post


Link to post

Never had a problem with RealPlayer. On my previous comp it was the only player that could handle HD video without stutter.

Share this post


Link to post

Phml said:
Anyone who believes Linux and average user can go together is utterly out of touch with reality, and anyone who interprets this as implying I dislike Linux is part of the problem.

The university where I studied swapped from Windows to Debian-based Linux, designing an OS that kind of acts, and even looks, like Windows, so people didn't note the changes too much, ensuring that the type of programs and services students and staff used were available. Steam OS would mainly have to concentrate on making game and service-related aspects convenient to users, with their financing to back the development. Reality is changing... and accelerating, in any case, which is the crux of the matter here.

Share this post


Link to post

Hope it won't be considered as a necrobump but I forgot to share the last news and I think it's the right place to do so.

Valve blog on Linux: http://blogs.valvesoftware.com/linux/

They managed to make L4D2 run faster on OpenGL than Direct3D (although they will port improvements to the later).

The interesting bit is that they already started to work on something we were talking about a page earlier:

Working with hardware vendors

We’ve been working with NVIDIA, AMD, and Intel to improve graphic driver performance on Linux. They have all been great to work with and have been very committed to having engineers on-site working with our engineers, carefully analyzing the data we see. We have had very rapid turnaround on any bugs we find and it has been invaluable to have people who understand the game, the renderer, the driver, and the hardware working alongside us when attacking these performance issues.
This is a great example of the benefits that are the result of close coordination between software and hardware developers and should provide value to the Linux community at large.


On another note, Serious Sam 3 is going to be ported on Linux by 2013.

Share this post


Link to post
Csonicgo said:

What needs to be done in Linux:

Sane Sound libraries (Not another pointless abstraction layer over 3000 more extraction layer)
Sane Display/IO systems like Wayland (http://wayland.freedesktop.org/) With major hardware vendor support

Unfortunately K!r4 has beat me to posting the link, but it's worth saying anyway.

Linux has these things already. I honestly don't see them as any kind of big issue, at all. It might be nice to replace X with Wayland or something else at some point in the future, but we have X already, and it works just fine, it has worked for years, and as you can see in the link above, speed isn't any problem either. As far as driver support goes, NVidia have done Linux drivers for years, and so have AMD.

Similarly for sound: I expect your beef with the audio libraries come from having seen a complicated diagram like this one. I've seen people post these in the past and they're always deeply misleading, because they throw in as much stuff as possible to make it seem like it's more complicated than it really is. The individual components have particular, specific purposes - BlueZ is the library used for Bluetooth communication, for example.

Share this post


Link to post

Theres this too, which is every bit as misleading too. It could potentially be made into a much more complicated-looking diagram, but it was made in response to that particular diagram for Linux :P

Share this post


Link to post
chungy said:

Theres this too, which is every bit as misleading too. It could potentially be made into a much more complicated-looking diagram, but it was made in response to that particular diagram for Linux :P

Exactly what I mean. I bet if you dug in more to what's going on behind the scenes you could make it look more complicated than that.

CSonicGo's complaint in a previous comment is about sound latency. Low latency audio output is actually a really tricky, difficult problem to address. To avoid stuttering you generally need an audio buffer to ensure a continuous stream of sound to the output device. The larger the buffer, the less chance of stuttering, but the more latency you add. Unsurprisingly, for most uses, stuttering is more of a problem than latency.

A friend of mine is a DJ and uses a laptop to do it, and it was interesting to hear about the setup he has to do it. To get decent low latency he has an expensive professional sound card - as I recall it came with a driver that provided custom APIs that allow the audio programs to do real-time guarantees. Despite the fact that he had this professional setup he was having problems with occasional stuttering. He suspected it was probably due to a driver for another device on the system. This was on Windows.

Share this post


Link to post
fraggle said:

CSonicGo's complaint in a previous comment is about sound latency. Low latency audio output is actually a really tricky, difficult problem to address. To avoid stuttering you generally need an audio buffer to ensure a continuous stream of sound to the output device. The larger the buffer, the less chance of stuttering, but the more latency you add. Unsurprisingly, for most uses, stuttering is more of a problem than latency.

Isn't this kind of fixed with RealTime-kernel? It is used in specific distro though.

Share this post


Link to post
K!r4 said:

Isn't this kind of fixed with RealTime-kernel? It is used in specific distro though.

Without more information / links about what you're specifically referring to I can't answer.

There isn't really a simple "fix" for this kind of problem. The simple fact is that if you really want low latency audio without stuttering, you need real time guarantees and tight integration between the hardware and software so that there are no gaps and the sound arrives in the buffer on time. When you buy an expensive professional sound card and professional music software, that's what you're paying for.

I expect that a custom kernel with mods to do real-time stuff is probably the cheap alternative way to get half-decent results out of commodity hardware. Several years back I remember there was a low latency kernel patch that reduced potential sources of latency, and that people were using for this sort of purpose. I don't know what's used nowadays though.

Share this post


Link to post

Wrong choice of words, sorry. Like you say, it isn't a fix.

Wikipedia:

The RT-kernel (RealTime-kernel) is a modified Linux-kernel, that alters the standard timer frequency the Linux kernel uses and gives all processes or threads the ability to have realtime-priority. (This means, that a time-critical process like an audio-stream can get priority over another, less-critical process like network activity. This is also configurable per user (for example, the processes of user "tux" could have priority over processes of user "nobody" or over the processes of several system daemons). On a standard Linux-system, this is only possible with one process at the same time.


I know it is used in Ubuntu Studio.

Share this post


Link to post
K!r4 said:

Wrong choice of words, sorry. Like you say, it isn't a fix.

Wikipedia:

Ah, so this, then. Interesting. I remember that long ago people used to use the preemptible kernel patch for this sort of thing, back when it was experimental - that eventually got integrated into the mainline kernel. Judging by this article it looks like this is an extension of that work. It's the kind of change that is unlikely to be merged into the main kernel because it's likely to break lots of subtle things.

I know it is used in Ubuntu Studio.

That would make sense, yes. It's good to see that there's a proper distro that comes with it all set up.

Share this post


Link to post

If actual real-time OS responses are needed, the solution would be something like QNX I guess.

Share this post


Link to post

I wonder if ChromeOS will support Steam natively ;D

Share this post


Link to post

Regarding Linux audio. Personally I believe that the Linux audio stack is quite good the way it is. People try to see everything as a "replacement for ALSA" when most things aren't. And of course anything above the software mixer level (PulseAudio/JACK) are usually cross platform libraries (3D sound, environmental audio, audio decoders/encoders, etc) which apply to all platforms anyways.

PulseAudio for example is actually a replacement for dmix. As for why it's not an ALSA extension like dmix, look no further than the Windows port. Why? Because PulseAudio provides network abstraction among other really powerful mixer features. Because of the way the Linux audio stack is right now, I can connect to a bluetooth device and forward some specific audio stream(s) to it without even thinking.

Nomad said:

I wonder if ChromeOS will support Steam natively ;D

Quite unlikely I think since the hardware isn't designed for gaming, and I'm sure chrome books don't have the disk space for games either. You're more likely to see native onlive support.

Share this post


Link to post

I think Gabe's plan all along was to take over the os scene, he created the software steam to rake in the needed cash to move forward.

Share this post


Link to post

Considering he's an ex-microsoft employee...

this is possible, actually. :0

Good to see they're making progress on the linux front, too, even though I don't use it.

Share this post


Link to post
Jonathan said:

In fact, something that caught my eye in that article somewhat backs up my theory:


Why hire kernel and device driver hackers if all they're doing is porting Steam and the Source engine?


Valve helped Apple tighten up their video drivers in preperation for OS X Steam, I guess they are going to do the same thing here.

Share this post


Link to post

Think about this.

Steam's not open-source, so that means it's not relying on any of the GPL dependencies. That means they are writing their own libs and APIs to replace them.

I would be surprised, in fact, if Steam Linux will have *any* external dependencies not written entirely by Valve.

This means it's unlikely to be subject to the degree of "it won't work on my install because I have version x.y.z of library foo" that most Linux programs are mired in.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×