The worst kind of an Internet-herpaderp. Internet-urpo pahimmasta päästä.
AFAIK the hype went overdrive because some performance numbers showed like 200-700 % higher framerates (https://www.phoronix.com/news/Linux-6.14-NTSYNC-Driver-Ready) - which were apparently comparisons to running games without e/f-sync vs ntsync.
Eeeeyyyyyyy, the wow64 option was the ticket. I was bypassing the redlauncher, but entirely possible either redext or cybertweak’s is 32bit dll and broke without the flag. Though performance of the game not really affected, probably entirely because I run it with RT enabled.
Yet again bitten in the ass by skipping a paragraph x)
Thanks!
hmhm, seems like some games don’t even start with NTSYNC on. I had heard that Cyberpunk specifically gets pretty nice performance boost, but I can’t even get it to start. Oh well.
ooh, nice. finally some ntsync support starts showing up. I’m not expecting miracles, but in general it still should (?) be better than existing e/f-sync thingies in general?
edit: probably depending on the application/game, but still. Nice to see things moving forwards.
well, they probably didn’t back when 510 drivers were a thing (as the link you provided links to 510.xx driver documentation), but later on they were enabled.
https://wiki.archlinux.org/title/NVIDIA/Troubleshooting#GSP_firmware
The use of the GSP firmware, enabled by default since version 555 of the NVIDIA driver released in June 2024, is known to cause a range of issues including Vulkan failures and system crashes.
and https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/gsp.html
The GSP firmware will be used by default for all Turing and later GPUs
Which nvidia driver you’re using? If you’re using the regular old nvidia blob, you might want to try disabling the gsp firmware. But note that this can’t be done with nvidia-open, only on nvidia.
Previously the gsp firmware was a bit problematic on some systems and wayland, disabling it solved some issues. But it has been fine since the 575 drivers, at least for me (rtx3090)
While I do agree, I dunno how meaningful or realistic data it would offer when some users switch between platforms.
huh? or did I miss something here?
edit: or are plain-text curlable websites a feature I’m not aware of? Or curl’ers use some striptags feature?
frames, probably not. But textures, geometry data, shaders and stuff like that, probably? I guess.
winevdm as in this https://github.com/otya128/winevdm ? I have used that on Windows before, and if I’m not entirely mistaken, isn’t it a part of wine anyway? At least winevdm.exe exists in my wineprefix.
One question is, how should one understand the GPU vram usage, when it is reported as 16.0/15.7 GB?
IIRC, using more vram than what’s on the card isn’t a show-stopper, just slow. The parts that don’t fit on the card just lay in RAM and are swapped back on card when needed. This is fairly slow and comes with a performance penalty, which is why the numbers are shown as red on there.
as for why it’s not showing full 16 GB as being the max? … no clue, probably the card needs some vram for it’s own operation/general framebuffer (or whatever is the term) for displaying eg. the os, not just the game. But I’m just guessing.
IIRC I have tried the game with proton(and/or -ge), it never worked on those.
I’m probably just going to accept dosbox for the game (it also fixes some minor graphics issues with it). I’m mostly concerned about old game installers - but then again, gog/steam don’t have those installers anyway, so it’s only an issue if the user is adamant on using original install media or so.
This update broke a game for me, namely “Castle of the Winds”, it’s a 16-bit windows 3.1 game. Not really a huge loss as I can just run it in win3.1 I have in dosbox - but it was pretty nice to have in modern resolution :D
Haven’t done much searching for remedies, but kinda looks like 16-bit support is gone https://bbs.archlinux.org/viewtopic.php?id=306297
Gotta wonder what’s the workaround, as many older games have 16-bit installers, even if the game was for eg. winxp or so.
I guess I could always just have an older wine on the side, but… I dunno. I’d like to keep it simple. :/
cool. in general the plain fps readout is enough for me, but a more comprehensive option sure doesn’t hurt. Hopefully that’ll come to linux as well.
Stiff linear ones are my thing, currently using Durock L7 78g ones. Haven’t really felt the need to seek alternatives as they’re nice, smooth and my sausage fingers don’t cause accidental keypresses when just resting them on keys :D
when your main stat is strength, and you’ve entirely ignored int/wis
Seriously though, if the cable doesn’t want to come out with reasonable force, the solution is PROBABLY NOT to apply more force. What kind of cavemen do you have working there?
Haven’t been following discord development, but I did test the screen sharing some days ago on linux - just for laughs - and to my surprise it didn’t CTD the app, and it actually streamed the thingy I wanted. Great!
Entirely possible, dunno. And not like a 3090 is that new anymore either.
Basically all of the issues mentioned above have been mentioned in various threads over at nvidia’s forums, etc. So they’re not unknown, but kinda wild a released driver has all of these issues whereas the previous beta was seemingly unaffected - feels like someone was bit too triggerhappy to release an untested version to production.
It’d be nice if I could just drop the nvidia card and swap to amdgpu but… that’d require “a bit” of money so I could maintain same (or better) level of performance - and atm I just don’t want to spend that kind of money. :/
heh, I was just watching it, saw your post about it. Thanks for making this!
The differences seem pretty minimal, although occasionally the frametime graph looks a bit less bumpy on ntsync side, but that’s about it. Even if the avg, 1% and so framerates are tad lower.