Quoting: reaVer@MayeulC: That was pretty informative, thanks. I'll come with a refutation when I come up with one ;)

You're welcome. I'll be happy to refute your refutation by then. (Or just to argue with it, I can recognize when I am wrong :) )

Quoting: slaapliedjeI do have to laugh at whomever it was earlier in this thread that said that Debian is so slow and they should have used Arch or Gentoo... I seriously notice no difference in speed between the two (actually I run Debian on an SSD, and Arch on a normal hard drive, so for me, Debian is way faster.) I'm just wondering why A) SteamOS still hasn't updated their installer so that it doesn't wipe out your drive. and B) It still shows it as being a beta on their site.

That's not me, but I must confess that when someone says Debian, I always think about the stable branch, which has quite outdated OSS graphics drivers.
Then, just my guesses :
A) It is designed for OEMs or someone who don't know what (s)he is doing, so wiping out the entire hard drive and partition automatically might be the safest bet. Moreover, if you install this as a gaming console in your living room, you probably only want to use SteamOS. Keep in mind it's designated for the broader audience.

B) I think it's just a mistake on their part, you should report this on github.

Regarding A) I think (but I am not sure, I haven't used debian in a long time) that you could just install a minimal Debian system, or say, Linux with apt-get, add the steam repo, and perform a dist-upgrade. I don't see why this wouldn't work.

View this comment - View article - View full comments

Quoting: reaVerEhm, I don't know how you can go more lower level than the most basic OpenGL calls. Don't forget that 90% of the OpenGL API is in fact redundant and if you look at the cleaner APIs such as OpenGL ES you will see that most of this stuff is in fact gone. I can imagine Vulkan making it easier, but not faster. I would again start with just the most basic problem, which is that they are using a distribution which is inherently slower than the top of the line such as gentoo and arch. And then drivers architecture, keep in mind that nvidia has used it's own architecture since its inception, so I'd guess it's probably optimized.

Keep in mind what I am going to say applies to Mantle (since I have more information about it), but also to Vulkan since it carries its legacy.
Actually, drawing a triangle with one of these APIs requires no less than 800 lines of code. For a triangle !
The developer is now responsible for low-level resource management/allocation, like memory. With previous APIs, you just kept uploading textures to the memory, until it was full, with little idea of what was remaining or how the driver managed the calls. Now, you can have a much finer control on resources, allocating what's needed, and minimizing copies, or keeping objects in memory for later.
The game developer is also responsible for draw calls, and any other form of communication with the device. Which means he can make those in batch, saving precious CPU time, and (maybe more importantly) in a multithreaded manner (provided he can manage the added complexity of multiple threads, that is.) Oxide games tested their game ashes of the singularity on a simulated infinitely fast GPU (I can't find the link to their article, unfortunately). They found that DX12 (which is close enough to Mantle/Vulkan) was capable of using all the CPU cores at 100%, whereas with the older API, only a core was always at full load. It has to do with the way OpenGL (and I think DX<12 too) uses their command buffer to send commands to the GPU, with the driver often running only on one core.
So, the area where the new APIs really shine are in CPU-bound scenarios, or when drawing multiple objects on screen (a lot of drawcalls). There are a few more points which are in favor of Vulkan, like built-in compute and multi-GPU capabilities, etc.
For more information, take a look at the DX12 demos. They should be quite representative of Vulkan, IMO.
There's also a handful Vulkan demos available (well, at least the results).
View video on youtube.com
View video on youtube.com
One added benefit of Vulkan is the simplicity of drivers. While that's not completely relevant with Gallium3D and such, you don't have to implement the whole OpenGL spec; since you let the developer take care of it.
Of course, the downside of all this is that it comes with added complexity for the developer. Moreover, Vulkan might not offer any substantial gain over OpenGL in some applications. On the plus side, there will very probably be some helper libs to help devs abstract away the complexity of Vulkan (thus, more or less recreating a complete OpenGL in the application :P); Moreover, from what I gathered, it seems possible to make Vulkan calls within an OpenGL context, at least on nVidia hardware (the opposite is probably possible too, but I didn't check).
So yeah, it looks somewhat like the golden apple of Linux gaming, and it's very promising for embedded systems and engine developers too.
I'm sure I forgot something, but there's really a lot to say about it :)

View this comment - View article - View full comments

Quoting: PeciskI personally don't think Vulkan is any kind of salvation here. Binary drivers just has to get better. Overall infrastructure has to get better. Also specific Steam Machine performance matters. People won't install SteamOS on their old boxes.

Actually,I think that Vulkan does matter : its main objective, like the one of the other next gen APIs, is to take the optimization responsibility away from the driver, and put it back in developer's hands. On the plus side, extremely good drivers are no longer needed. On the other side... Bad developers will roll out even worse games (and they should stick with OpenGL, IMO). We could even see some game-specific Vulkan shader optimization in the proprietary drivers, if game developers are unable to code/test/debug properly.

Also, someone could turn a steambox into a lovely retro console :)

Edit : sub, you beat me by 2 minutes ;)

View this comment - View article - View full comments

Quoting: Purple Library GuyThat is frankly the Achilles' heel of the Steam machine, much as I hate to say it: There's no compelling reason from the consumer perspective why the thing should be running SteamOS rather than Windows, and significant reasons in the other direction. That could change, I hope it will change, but it remains something of a chicken-egg problem so far, although already not nearly as bad as it was just a year or two ago.

On the other hand, assuming they do get pulled from the Steam Machine page on Steam, good luck making up for that with whatever other sales channels you got, Origin guys.

Actually, using SteamOS, you won't be annoyed with any of windows' aspects. No updates that automatically restart your computer, no bloatware, no viruses, etc. I can totally see how it would be appealing to a windows consumer. But it's true that these points are easily forgotten.

View this comment - View article - View full comments

It's a great idea to put tutorial like these on this site, most notably for people who are new to Linux/SteamOS

I think it would be great if someone could post here a tutorial explaining how to get emulators running, as well as installing a package manager. I do not have time to do it myself yet, but if it hasn't been done by the time I get some spare time in my hands, I'll write one for sure. I've pointed out Lutris as a possible solution in the past, but I don't really know if it's difficult to get it running on SteamOS.
Edit: the official Minecraft launcher is publicly available from here [External Link], as listed there [External Link]. I don't really see why you didn't include it.
Edit2: One could just provide a .deb with minecraft too, no?

View this comment - View article - View full comments

Very nice sice screenshot.

We still want to port our game but we either will have to wait for our financial situations to improve or rely on our community help. If anyone is willing to help us with it, please let us know.

I would love to help them port it over to Linux. But an entire engine is a very difficult beast to tame, even more so if there is few people working on it (there are exceptions, of course: in dying light's case, there were only two devs working on the port; then, there's Icculus and others :)). Moreover, I have a lot of ongoing projects. So, not anytime soon, for me at least.
Any volunteer?

View this comment - View article - View full comments

Quoting: OrkultusI wonder if you could use this out of game as well. For your entire computer. Would be great practice.

AFAIK, steam allows to configure it for use outside of big picture.

View this comment - View article - View full comments

Thanks for this review :)

I've personally refrained myself multiple times from clicking on the checkout button... I think I'll wait for the next iteration or revision. Well, at least if I can resist the temptation until then ;)

View this comment - View article - View full comments

Well, then a shader cache should do the trick. As well as parallel shader compilation, both of which are coming to the OSS drivers in a not to distant future.

I didn't forget about this title; I just checked it yesterday ;)

View this comment - View article - View full comments

Any clue about the engine it uses ?

This could be interesting with steamVR, I guess. Maybe not playable, but at least interesting.

View this comment - View article - View full comments