Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: AnanaceI just realized that if they collaborate with Valve a bit, this could make a great Steam Link device as well - seeing as they seem to be sunsetting that hardware, just write up a Steam Link app version for the Atari OS and add support for the native Steam Controller communication. (should be possible with a regular bluetooth chip and custom firmware as that's what the controller itself uses)
Or heck, just connect the controller over bluetooth, since the Steam Link already means network streamed games a tiny bit more latency (4-5ms) for the bluetooth stack won't be noticeable.

Of course, you should just be able to run the regular steam client in the other OS, but never hurts to support such things natively.

I think the Steam Link is an ARM device, isn't it? So there would be needed some porting. But could be a nice minimal thing.

While the steam link is arm don't forget that the desktop client also supports streaming and that's x86. All they need to do is make a stripped down version of that.

Yeah, but I mean how stripped down can you get compared to the Link? The Link does (if I recall) run a Linux kernel already. So yeah it wouldn't be hard to just port that. Though I think others have reported that their AMD based systems ran poorly with it, and the VCS is AMD based, so not sure where the streaming would be hardware accelerated at that point.

Either way, I ordered another Link, and I found a 'hack' online that tells you how to tweak the maximum throughput. I haven't tried it yet though.

Interesting? I have an AMD system but I don't stream my games to it since it's my primary gaming machine however I would think performance should be fine. I'd have a really hard time believing valve was doing anything weird enough to warrant a performance degredation like that. Also yes, the link does run Linux.

What I had read was the streaming to the Link uses nvenc, which is missing on AMD systems, so they don't work as well. So it's specific to the streaming component, not AMD performance itself.

NVENC is a proprietary Nvidia technology. I doubt the link has that.

https://www.reddit.com/r/Steam_Link/comments/5315v0/higher_display_latency_when_using_nvenc/ [External Link]
Sure looks like it's an option.

This sounds like he's streaming to a desktop machine with an nvidia card, not a steam link.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: AnanaceI just realized that if they collaborate with Valve a bit, this could make a great Steam Link device as well - seeing as they seem to be sunsetting that hardware, just write up a Steam Link app version for the Atari OS and add support for the native Steam Controller communication. (should be possible with a regular bluetooth chip and custom firmware as that's what the controller itself uses)
Or heck, just connect the controller over bluetooth, since the Steam Link already means network streamed games a tiny bit more latency (4-5ms) for the bluetooth stack won't be noticeable.

Of course, you should just be able to run the regular steam client in the other OS, but never hurts to support such things natively.

I think the Steam Link is an ARM device, isn't it? So there would be needed some porting. But could be a nice minimal thing.

While the steam link is arm don't forget that the desktop client also supports streaming and that's x86. All they need to do is make a stripped down version of that.

Yeah, but I mean how stripped down can you get compared to the Link? The Link does (if I recall) run a Linux kernel already. So yeah it wouldn't be hard to just port that. Though I think others have reported that their AMD based systems ran poorly with it, and the VCS is AMD based, so not sure where the streaming would be hardware accelerated at that point.

Either way, I ordered another Link, and I found a 'hack' online that tells you how to tweak the maximum throughput. I haven't tried it yet though.

Interesting? I have an AMD system but I don't stream my games to it since it's my primary gaming machine however I would think performance should be fine. I'd have a really hard time believing valve was doing anything weird enough to warrant a performance degredation like that. Also yes, the link does run Linux.

What I had read was the streaming to the Link uses nvenc, which is missing on AMD systems, so they don't work as well. So it's specific to the streaming component, not AMD performance itself.

NVENC is a proprietary Nvidia technology. I doubt the link has that.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Scoopta

Quoting: slaapliedje

Quoting: AnanaceI just realized that if they collaborate with Valve a bit, this could make a great Steam Link device as well - seeing as they seem to be sunsetting that hardware, just write up a Steam Link app version for the Atari OS and add support for the native Steam Controller communication. (should be possible with a regular bluetooth chip and custom firmware as that's what the controller itself uses)
Or heck, just connect the controller over bluetooth, since the Steam Link already means network streamed games a tiny bit more latency (4-5ms) for the bluetooth stack won't be noticeable.

Of course, you should just be able to run the regular steam client in the other OS, but never hurts to support such things natively.

I think the Steam Link is an ARM device, isn't it? So there would be needed some porting. But could be a nice minimal thing.

While the steam link is arm don't forget that the desktop client also supports streaming and that's x86. All they need to do is make a stripped down version of that.

Yeah, but I mean how stripped down can you get compared to the Link? The Link does (if I recall) run a Linux kernel already. So yeah it wouldn't be hard to just port that. Though I think others have reported that their AMD based systems ran poorly with it, and the VCS is AMD based, so not sure where the streaming would be hardware accelerated at that point.

Either way, I ordered another Link, and I found a 'hack' online that tells you how to tweak the maximum throughput. I haven't tried it yet though.

Interesting? I have an AMD system but I don't stream my games to it since it's my primary gaming machine however I would think performance should be fine. I'd have a really hard time believing valve was doing anything weird enough to warrant a performance degredation like that. Also yes, the link does run Linux.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: AnanaceI just realized that if they collaborate with Valve a bit, this could make a great Steam Link device as well - seeing as they seem to be sunsetting that hardware, just write up a Steam Link app version for the Atari OS and add support for the native Steam Controller communication. (should be possible with a regular bluetooth chip and custom firmware as that's what the controller itself uses)
Or heck, just connect the controller over bluetooth, since the Steam Link already means network streamed games a tiny bit more latency (4-5ms) for the bluetooth stack won't be noticeable.

Of course, you should just be able to run the regular steam client in the other OS, but never hurts to support such things natively.

I think the Steam Link is an ARM device, isn't it? So there would be needed some porting. But could be a nice minimal thing.

While the steam link is arm don't forget that the desktop client also supports streaming and that's x86. All they need to do is make a stripped down version of that.

View this comment - View article - View full comments

I just read the medium article and I saw two things that are a bit concerning. Both are things that will make porting to PC Linux from the VCS more difficult depending on the dev. The first is the fact that they might use an Atari custom audio library. It will use an ALSA backend and I'm sure devs can still use ALSA directly but they might not which would potentially tie them to the VCS. Not to mention lack of pulse isn't great IMO either. The far more concerning thing is the fact that while it will have OpenGL and Vulkan they also mention it will have hardware command buffer rendering which is something impossible in the PC world due to the wide variety of hardware. If games use that then porting from the VCS is just as hard as any normal console. I'm sure not a lot of games will use that since I assume that'll only be used by devs where even Vulkan has too much overhead but it is a possibility.

View this comment - View article - View full comments

Quoting: danniello

Something along the lines of: if you plug in a bootable external USB drive our hypervisor will boot from it, otherwise it will boot the internal Atari OS.

LOL. If I interpret it correctly - hypervisor means that "other OS" will be started as VM in KVM/Xen hypervisor. It means no real GPU acceleration in VM. Even closed source solutions like VMware do not provide good GPU acceleration in VM - max. DirectX10/OpenGL. As today only GPU passthrough is the best GPU solution for VM, but... it require very expensive corporate edition of GPU (for example nVidia Quadro) or separate consumer GPU.

In my opinion - it doesn't make sense. Why?! Because "Atari OS" has to be protected?! Against who?! Crackers (if interested anyway in niche console) probably will crack their "lock-in" very easily.

Woah woah woah there. I don't think you understand how this can work. First off, you can do pass through with a single GPU. All it means is the hypervisor can't draw to the screen only the guest can. Why does that matter for this? It doesn't. Second are you aware the Xbox One also does the same thing? It uses a hypervisor with either Xbox OS or Windows 10 as the guest depending on if you load an Xbox game or a UWP app. You don't need expensive enterprise GPUs or even 2 consumer GPUs. You just make the hypervisor headless. As for why they do it who knows but I could take a guess that it makes supporting multiple OSes easier. The hardware doesn't need to be quite as standard since the hypervisor will abstract it but that's just a theory.

View this comment - View article - View full comments

Quoting: massatt212

Quoting: ScooptaWhile I'm looking forward to this I'm a bit worried it won't run for me. Rise of the tomb raider hangs for me on RADV 18.2.5. A lot of DXVK games also hang for me although not all of them. Hopefully by the time this comes out it won't be an issue anymore.

Are you running
Ubuntu or Arch ? cause im stuck at 18.2.2 on Ubuntu

Debian sid

View this comment - View article - View full comments

While I'm looking forward to this I'm a bit worried it won't run for me. Rise of the tomb raider hangs for me on RADV 18.2.5. A lot of DXVK games also hang for me although not all of them. Hopefully by the time this comes out it won't be an issue anymore.

View this comment - View article - View full comments

Quoting: Nevertheless

Quoting: Scoopta

Quoting: Nevertheless

Quoting: Scoopta

Quoting: Whitewolfe80

Quoting: Scoopta

Quoting: orochi_kyoLOL, its funny to see people happy or fine with a dev lying straight to their faces.
"At least they didnt hide", you say. So lying is any better?
So they didnt know Linux has many distros before promising a linux version?
Its obvious they use the linux thing to get more crowdfunding money, when they have to deal with reality, they just leave the boat as the rats they are.
Devs should only support Ubuntu, yeah it sound elitist, but its better so devs stop bullshitting to their backers with the "too many distros" pretext. Also having two linux distros on your computer isnt rocket science.
I recommend linux backers to ask for a refund, take that money to a more serious developer.

I agree that devs should pick one distro and not worry about the rest however I think the real solution should be making the steam runtime a full container environment so nothing but the kernel from the underlying system is used. That would fix all of these issues as devs could target that container.

Dont they already do that though pretty much every linux dev says just target steam run time libaries then it run on everything linux, Back on topic here though am fairly certain it will run on proton no problem given its using stock engine with custom art assets. I was looking forward to it but broken port promise means ill never buy it.

Steam adds a whole bunch of libraries into the LD_LIBRARY_PATH but devs can opt to use system libraries and any libraries not included in steam end up provided by the system anyway. I think moving steam to flatpak or containerizing steam games would fix the issues. It would also make steam larger as it would have to include every dependency a game needed but it's the only way to fix some of these issues.

Steam is on Flathub and it's working great!

Someone else mentioned this...I might actually have to try the flatpak.

Yes, some way up! Only things you have to know:
Your steam libraries have to be (or have to have mountpoints) inside the flatpak dir. The Flathub Steam flatpak cannot access your filesystem. For more or other access rights you'd have to build your own flatpak container.
As far as I know you cannot provide command line parameters to the steam binary inside the flatpak.
All your savegames are stored inside the Steam flatpak dir, not in your home folder.
All flatpak dirs are stored inside ~/.var/app/
They do not always provide runtimes for all latest Nvidia drivers (about AMD I don't know). Latest driver working atm is 410.73.

They provide mesa for AMD although I didn't check the version. Also flatpak should pass arguments to the program if you provide them after the package name. I.e flatpak run com.valvesoftware.Steam [args]. I ended up trying the flatpak in an attempt to fix an issue caused by the Debian build of RADV but unfortunately the flatpak runtime also builds RADV against LLVM 6 which causes hangs in Vulkan and DXVK games. I was really hoping I could fix my issues but unfortunately it seems both the flatpak and Debian use LLVM 6.

View this comment - View article - View full comments

Quoting: Nevertheless

Quoting: Scoopta

Quoting: Whitewolfe80

Quoting: Scoopta

Quoting: orochi_kyoLOL, its funny to see people happy or fine with a dev lying straight to their faces.
"At least they didnt hide", you say. So lying is any better?
So they didnt know Linux has many distros before promising a linux version?
Its obvious they use the linux thing to get more crowdfunding money, when they have to deal with reality, they just leave the boat as the rats they are.
Devs should only support Ubuntu, yeah it sound elitist, but its better so devs stop bullshitting to their backers with the "too many distros" pretext. Also having two linux distros on your computer isnt rocket science.
I recommend linux backers to ask for a refund, take that money to a more serious developer.

I agree that devs should pick one distro and not worry about the rest however I think the real solution should be making the steam runtime a full container environment so nothing but the kernel from the underlying system is used. That would fix all of these issues as devs could target that container.

Dont they already do that though pretty much every linux dev says just target steam run time libaries then it run on everything linux, Back on topic here though am fairly certain it will run on proton no problem given its using stock engine with custom art assets. I was looking forward to it but broken port promise means ill never buy it.

Steam adds a whole bunch of libraries into the LD_LIBRARY_PATH but devs can opt to use system libraries and any libraries not included in steam end up provided by the system anyway. I think moving steam to flatpak or containerizing steam games would fix the issues. It would also make steam larger as it would have to include every dependency a game needed but it's the only way to fix some of these issues.

Steam is on Flathub and it's working great!

Someone else mentioned this...I might actually have to try the flatpak.

View this comment - View article - View full comments