What about macos?
Linux gaming is faster because Windows APIs are becoming Linux kernel features
71–80 of 694 posts
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#72Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#73Used to be a staff member working on an x86 OS called CTOS. I realized if I implemented a couple of traps, we could run command-line DOS programs. So I did. And it worked. Dev tools, text processing, piped commands all worked. It helped that the DOS executable format was the same as the CTOS format - because we had traded Bill Gates our linker (which produces executables) for his BASIC compiler.
if I implemented a couple of traps
What does this mean? System calls?
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#74If you purpose build a Linux gaming PC, would you lean more towards AMD GPUs over Nvidia?
End of 2024 I did exactly that. Ryzen and RADEON all the way. Rocking Fedora right now but was using Ubuntu for a bit. I have no reason to use Windows at all.
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#75Earlier quoted context omitted.
People say you will have less problems with AMD but I am using a Nvidia GPU for years now (on Cachyos and Pop OS) without issues. I'm using Steam and Proton pretty much exclusively though.
Nvidia on desktop has been mostly fine, if not rock solid, on the happy path they provide. But their happy path hasn't included proper wayland support for a long time. Nvidia on laptops? Insert the famous Linus Torvalds meme here
> Nvidia on laptops? Insert the famous Linus Torvalds meme here
I have an RTX 5070 (whatever the laptop variant is) and it absolutely rocks with almost everything I throw at it, running Ubuntu+Steam+Proton. I no longer worry whether a Windows game is going to run, because almost all of them do with good performance.
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#76Earlier quoted context omitted.
any reason why we are using hdmi over display port?
For one, DisplayPort doesn’t support HDR output
That can't be right. I'm reading this comment on an HDR monitor over DP right now.
Don't all USB-C video outputs use DP alt mode too, with an HDMI adapter at the end? And they can do HDR.
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#77I developed for windows before moving to linux. I was surprised to find that was no system call similar to windows WaitForMultipleObjects. Sure you can implement something similar using poll() or using condition variables. but WaitForMultipleObjects seems so much simpler and more versatile
A lot of that flexibility is what makes it hard to efficiently emulate (especially without kernel level support), but some of it seems too flexible to make sense as the default choice. How often does a video game really need a lock that can be shared between processes, and why should that lock type be the one that a game engine uses for almost all of its locks?
> How often does a video game really need a lock that can be shared between processes,
What do you mean? SRWLock (or the older CRITICAL_SECTION) cannot be shared between processes. A (Win32) Mutex does work across processes, but that's its entire purpose. So Windows does have different tools for different jobs.
In fact, it's really the other way round: on Linux, a futex also works across processes, but there is no equivalent in Windows. (Sadly, WaitOnAddress can only be used in a single process.)
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#78Earlier quoted context omitted.
any reason why we are using hdmi over display port?
For one, DisplayPort doesn’t support HDR output
The cable length limitations are also a pain in the ass for not-uncommon A/V system configurations. 6' recommended max, and the best you might get working stably if the device and cable gods smile on you is 15'. 6' is the lower edge of acceptable for just about any A/V system setup (in practice it means your devices need to be within about a meter of the screen's port[s], which is pretty close) and even 15' is still too short to be useful for, say, a projector, or a "the A/V receiver or HDMI switch is over in that cabinet, the TV is on this wall across the room" situation.
HDMI goes 25'+, no problem.
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#79I developed for windows before moving to linux. I was surprised to find that was no system call similar to windows WaitForMultipleObjects. Sure you can implement something similar using poll() or using condition variables. but WaitForMultipleObjects seems so much simpler and more versatile
A lot of that flexibility is what makes it hard to efficiently emulate (especially without kernel level support), but some of it seems too flexible to make sense as the default choice. How often does a video game really need a lock that can be shared between processes, and why should that lock type be the one that a game engine uses for almost all of its locks?
How often does a video game really need a lock that can be shared between processes,
That seems hugely useful for interprocess communication and I can immediately think of reasons to use IPC in a game. Having a separate voice process for one.
Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features
#80If you purpose build a Linux gaming PC, would you lean more towards AMD GPUs over Nvidia?
both are shit I used a recent nvidia blackwell GPU with linux, periodic crashes. Blackwell generation is shit. Used recent builtin AMD GPU... Even worse, super reproduceable X crashes when using firefox
In good faith, you can't really say "[x] is shit" if you don't have an usual setup; X11 is no longer the default on most distros. Even when I was also using it, it never crashed.
I don't know whether your GPU is older than mine or not but I have the RX 7700XTX. Maybe it had a software defect...