Croteam are continuing to improve The Talos Principle [Steam] with a brand new stable build that has Vulkan optimizations.
Changelog:
QuoteImprovements:
- General stability and performance improvements on Vulkan API.
Bug fixes:
- Fixed a rare crash in multi-threaded instanced rendering.
- Fixed potential artifacts when using occlusion culling.
For me, I've found the Vulkan version does perform a lot better than the original OpenGL version, so here's to hoping they continue to improve it. This also has me excited for their revamp of the Serious Sam games with Vulkan on their Fusion engine.
Some you may have missed, popular articles from the last month:
Quoting: SolitaryI think I experienced those black screen crashes, I don't know if they are the same, maybe they fixed those already, did you try SSH? Your machine actually might have still lived, because when I experience those freezes I can't jump into console either, I think it's because keyboard does not respond (classic numlock test), because Xorg is "busy", but SSH still works.
At that time I was not aware that it was possible to recover the system outside of ctrl + alt + f1 (my first crash of that kind since 6 years on GNU / Linux / Ubuntu probably ^^), and as the system was hard-locked I was not able to search online for a solution. ^^'
0 Likes
I used to have the black screen crashes, but haven't had them since the 375 driver.
0 Likes
Quoting: Purple Library GuyVulkan improvements. So, pointier ears?
That's next update, this one is less feels.
1 Likes, Who?
Now I got 30+ more FPS in average according to the built-in benchmark compared to earlier results. Neat. :D
Last edited by ttyborg on 14 February 2017 at 10:44 pm UTC
Last edited by ttyborg on 14 February 2017 at 10:44 pm UTC
1 Likes, Who?
Crashes here too, sometimes to desktop and sometimes freezes hard enough to need ssh help, logs are full of
leading to the crash. There's graphics corruption too.
It seems to work with GPU memory setting set to lowest, but it's not exactly a pleasant experience with that - autodetect selects the memory setting as "High" for the card (Geforce 960, 2GB) and OpenGL renderer works fine with that.
(The old version was exactly same so I don't have any regressions in this regard, but alas no improvement either)
Last edited by Juhaz on 14 February 2017 at 11:02 pm UTC
00:31:32 INF: Trying to allocate device optimal memory pool of X MB for Y KB object... failed! (0 MB of VRAM already allocated)
00:31:32 ERR: Vulkan: Out of memory! (CreateSurface, allocate memory)
leading to the crash. There's graphics corruption too.
It seems to work with GPU memory setting set to lowest, but it's not exactly a pleasant experience with that - autodetect selects the memory setting as "High" for the card (Geforce 960, 2GB) and OpenGL renderer works fine with that.
(The old version was exactly same so I don't have any regressions in this regard, but alas no improvement either)
Last edited by Juhaz on 14 February 2017 at 11:02 pm UTC
0 Likes
[quote=riusma]
Remember Alt + SysRq + REISUB (http://askubuntu.com/a/36717/31099)
To remember REISUB, you can either:
- Remember that it's BUSIER backwards
- Reboot Even If System Utterly Broken
This has been quite useful for me, especially when coding real-time kernel modules (and inevitably a bug freezing the whole system). It has also been useful when I was affected by a bug related to swap which made turning off super slow (minutes), so I could just turn off the computer safely and quickly.
Pay extra attention to the S (sync) and U (remount read-only) commands, as they are what really make the reboot safe.
Quoting: SolitaryHard lock of the system with black screen, ctrl + alt + f1 was not responding... so hard reboot (which isn't a good idea, I've read that there is a more secure way to reboot the system... should note that somewhere for my next adventure in Vulkan's lands ^^)
Remember Alt + SysRq + REISUB (http://askubuntu.com/a/36717/31099)
To remember REISUB, you can either:
- Remember that it's BUSIER backwards
- Reboot Even If System Utterly Broken
This has been quite useful for me, especially when coding real-time kernel modules (and inevitably a bug freezing the whole system). It has also been useful when I was affected by a bug related to swap which made turning off super slow (minutes), so I could just turn off the computer safely and quickly.
Pay extra attention to the S (sync) and U (remount read-only) commands, as they are what really make the reboot safe.
1 Likes, Who?
[quote=ShabbyX]
Isn't it Ctrl+Alt+SysRq?
I personally used to remember it with "Raising Elephants Is Simply, Utterly, Boring"
Note that some SysRq must be activated before they work. And the kernel might be compiled without, IIRC.
I also like Ctrl+Alt+SysRq+ F
That calls the OOM killer, which will kill the process with the largest amount of memory. That's useful when a program makes the system unresponsive because of swapping.
Otherwise, I think a Ctrl+Alt+SysRq+R might give you back the ability to switch to a VT (that is, if your graphics card didn't completely lock-up).
Back on the topic, it's really nice to hear continued improvement on Vulkan games and drivers. I can't wait to have a Vulkan-capable graphics card \o/ (Vega, I'm waiting for you).
Quoting: riusmaQuoting: SolitaryHard lock of the system with black screen, ctrl + alt + f1 was not responding... so hard reboot (which isn't a good idea, I've read that there is a more secure way to reboot the system... should note that somewhere for my next adventure in Vulkan's lands ^^)
Remember Alt + SysRq + REISUB (http://askubuntu.com/a/36717/31099)
To remember REISUB, you can either:
- Remember that it's BUSIER backwards
- Reboot Even If System Utterly Broken
This has been quite useful for me, especially when coding real-time kernel modules (and inevitably a bug freezing the whole system). It has also been useful when I was affected by a bug related to swap which made turning off super slow (minutes), so I could just turn off the computer safely and quickly.
Pay extra attention to the S (sync) and U (remount read-only) commands, as they are what really make the reboot safe.
Isn't it Ctrl+Alt+SysRq?
I personally used to remember it with "Raising Elephants Is Simply, Utterly, Boring"
Note that some SysRq must be activated before they work. And the kernel might be compiled without, IIRC.
I also like Ctrl+Alt+SysRq+ F
That calls the OOM killer, which will kill the process with the largest amount of memory. That's useful when a program makes the system unresponsive because of swapping.
Otherwise, I think a Ctrl+Alt+SysRq+R might give you back the ability to switch to a VT (that is, if your graphics card didn't completely lock-up).
Back on the topic, it's really nice to hear continued improvement on Vulkan games and drivers. I can't wait to have a Vulkan-capable graphics card \o/ (Vega, I'm waiting for you).
1 Likes, Who?
[quote=ShabbyX][quote=riusma]
I originally learned it wih "Raising Elephants Is Utterly Boring". :D
Quoting: SolitaryTo remember REISUB, you can either:
- Remember that it's BUSIER backwards
- Reboot Even If System Utterly Broken
I originally learned it wih "Raising Elephants Is Utterly Boring". :D
0 Likes
[quote=beniwtv][quote=ShabbyX]
Quoting: riusmaRead my comment, you forgot the "sync" part ^^Quoting: SolitaryTo remember REISUB, you can either:
- Remember that it's BUSIER backwards
- Reboot Even If System Utterly Broken
I originally learned it wih "Raising Elephants Is Utterly Boring". :D
0 Likes
Quoting: M@yeulCIsn't it Ctrl+Alt+SysRq?
Nope, ctrl is not needed: https://en.m.wikipedia.org/wiki/Magic_SysRq_key
1 Likes, Who?
See more from me