Thank you for listening! I hope you'll solve that issue of yours.

View this comment - View article - View full comments

Unfoooooortunately, Early Access starts with Windows only. Mac/Linux will be added later so don't be overexcited. Yet.

From the Store Page [External Link]:

Windows 64bit will be the only initial operating system supported, though we will be rolling out support for Mac OS, Linux and Steam OS over time.

View this comment - View article - View full comments

Quoting: wolfyrionA good or a bad review plays a huge role before buying a game and a lot of people are trusting GOL for its reviews.

This. GOL is a huge and trustworthy source for many Linux gamers. I expect it to stay the same and not to become a FUD source. DL has many flaws (while being a great game nevertheless!) but proclaiming any unique quirks as Techland's fault that broke the game for everyone SO DON'T UPDATE FOLKS UNTIL THEY FIX THEIR SHIT — that's just unfair, highly subjective and reduces the GOL's credibility. Please, please double check such claims, it's not like there are many competing Linux gaming sites so you have to publish as fast as you can to get views first.

BTW, the update was for the Steam Workshop content [External Link]. Maybe it's also good&fair to change the title of this article? Doesn't look good on the main page...

View this comment - View article - View full comments

Works fine on Debian testing, 770 GTX/358.16 (downgraded because of performance hit in 36x.xx). Is there anyone having crashes after the update apart from The Boss, hm? Despite the poor game state on Linux, it's not good to blame Techland for own issues with libs or whatever...

View this comment - View article - View full comments

Quoting: BeamboomExcept, this is a port. :D

What is port?

Spoiler, click me

Baby don't hurt me, don't hurt me, no more

I mean, what qualifies as a port and what is just a game released on several platforms? On which platforms it's not a port and on which it is? I'd understand it being called a port if it were released on Windows first and on Mac/Linux later but that's not the case. The release was simultaneous.

View this comment - View article - View full comments

There was a hotfix released [External Link] but it didn't hit the Linux playerbase for whatever reason. SteamDB [External Link] shows that the public branch is at 981411 build id while Steam itself says it's 960248 (equals to mac_linux_1_0 branch). I didn't know that branch pointers are per-platform. Or is it just me?

View this comment - View article - View full comments

Quoting: turolFrom the specification section 2.5:
"... implementations must ensure that incorrect usage by an application does not affect the integrity of
the operating system, the Vulkan implementation, or other Vulkan client applications in the system, and does not allow
one application to access data belonging to another application. Applications can request stronger robustness guarantees
..."

So a misbehaving application should only be able to crash itself assuming there are no OS/driver bugs.

Thanks, that's a strong point!

Quoting: STiATVulkan does not let you just access the hardware, just because it's closer to it, it's not a direct access. It basically just gives you more control about command queues and buffers, within a few other things. But you still have to get a command buffer by the driver (you request a buffer of a kind and size and the driver supplies you with that), that didn't change :p.

Vulkan applications still have their OWN LOCAL buffers, which the driver better does not get mixed up with other buffers reserved on the GPU. Getting Vulkan to be displayed on X11 and/or keeping different applications not getting in each others way is the responsibility of the driver (still).

But ye, you for sure can kill the driver with Vulkan, as much as you could with OpenGL (locking up the GPU).

And this perfectly complements it. I'm relieved now.

BTW, what if Wine/eON implements their D3D translation in Vulkan? Could it give any significant boost or reduce hitching?

View this comment - View article - View full comments

Quoting: minjThe error checking is a different layer in Vulkan that can be enabled in dev and disabled in production. This should theoretically take care of all the major problems before they hit users. Then again AAA titles should be obvious bug-free on launch and we all now how take works...

My concern exactly. For now a buggy shader may prevent rendering some parts of the scene like skin in Assassin's Creed. Looks awfully but at least you can exit the game. If the entire desktop hangs up instead (together with unsaved documents and what else), gamers would be not just upset but furious.

In the meantime you may check these demos [External Link] (from this source [External Link]. They require Vulkan SDK [External Link] (sign in isn't required, look at the bottom) and the mentioned source repository. Binaries are supposed to be placed in the subdir of the cloned repo, I named it "binaries" so that they could access the data files with ../data/shaders/whatever). computeshader crashes for me and instancing is unbelievably slow. Which is sad as it says lots about the expected gain. Or loss of it.

View this comment - View article - View full comments

Quoting: skinnyraf

Quoting: rkfgI've become curious about one thing: if Vulkan provides such a low level access to hardware, what will happen if an app (a game usually) starts to misbehave?
<...>

Is it any better with OpenGL? It's direct access too. A misbehaving game/driver can easily freeze a system. You can sometimes switch to a console to kill the game, but often it is not possible. You could still ssh into the box if you have another system available, but how many users can do it?

Technically, yes. I had XCOM 2 freezing the driver completely with Xorg. Connected via SSH from tablet, killed X but the image on screen remained. Couldn't rmmod nvidia (module is in use), had to reboot. So yes, OpenGL can break the system. But it has enough layers of protection to prevent many possible ways of doing that unintentionally. Vulkan, as I understand it, has none or very few. So here comes a question, do we agree to trade stability for performance? A hard one to answer I must say.

View this comment - View article - View full comments

I've become curious about one thing: if Vulkan provides such a low level access to hardware, what will happen if an app (a game usually) starts to misbehave? I read Vulkan has very little validation in favor of speed. Does that mean that a buggy game could crash the entire Xorg or freeze the driver? A user-space segfault usually leads to crashing the program but not the entire system (and Xorg/desktop for many people is the system), but if invalid data goes into the kernel space or the Xorg driver and crashes there because of that... I suppose it would be bad. Kernel panic for the module and Xorg crash in case of the Xorg driver.

View this comment - View article - View full comments