Fedora 38 LLVM vs. Team Fortress 2

Post by pedrocr » Tue, Apr 25, 2023, 9:57 AM UTC

Dalewyn wrote: post #90

mjg59 wrote: post #73

Earlier quoted context omitted.

This is largely solved with approaches such as Flatpak or Snap, but graphics drivers are still an issue - they're expected to be supplied by the distribution, and components of them end up in-process in the application even if the rest of the application's runtime is shipped with the application. If there's an incompatibility between the application runtime and assumptions made by that driver code (as there appears t…

>I don't think there's anything about Windows that would fundamentally change things here. Windows apps aren't shipping their own graphics drivers, even if they're bundling everything else. Over on Windows, GPU drivers are provided and distributed by the manufacturer, Microsoft themselves might also distribute them through Windows Update. GPU manufacturers also work together with Microsoft and bigger game dev studios…

Post by ungamedplayer » Tue, Apr 25, 2023, 10:32 AM UTC

stabbles wrote: post #43

gabcoh wrote: post #35

Earlier quoted context omitted.

Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?

LD_PRELOAD is too global to be useful, it's hard to scope it to one process (and not child processes). macOS is better in the sense that it clears DYLD_* variables when the dynamic linker has done its work and the process starts. (Although that can also be painful when you want to run a shell script and set DYLD_* outside)

Post by nemetroid » Tue, Apr 25, 2023, 12:27 PM UTC

zamnos wrote: post #92

pedrocr wrote: post #91

Earlier quoted context omitted.

Getting consistent quality out of Linux drivers is usually much easier than Windows ones exactly because they're not supplied by a random hardware maker but are almost all upstream in the kernel. GPU drivers used to be a nightmare for this exact reason and are now finally all becoming properly upstream. Meanwhile the horror stories about Windows GPU drivers are all too common. Having to "clean up" old drivers. Having…

Let's be real, the two contenders for GPU performance (which, gamers appreciate) are Nvidia, which is not in the kernel, and AMD, which has an in-kernel driver, plus their own proprietary driver, same as Nvidia. TF2 is old enough that its runnable even on old Intel hardware, but let's not pretend that "almost all [drivers are] upstream in the kernel", so long as Nvidia and AMD both have proprietary, out-of-kernel-tre…

Post by nemetroid » Tue, Apr 25, 2023, 12:33 PM UTC

olliej wrote: post #61

viraptor wrote: post #25

Earlier quoted context omitted.

> and then just repeatedly allocate in the hope that you will eventually get a correctly aligned value out If you preload something that patches all the new/delete interfaces, you can do this without guesswork. new(size, alignment) -> res=alloc(size+alignment) res_aligned=res+... offsets[res_aligned] = res new(size) -> alloc(size) free(ptr) -> free(offsets[ptr] || ptr) offsets.del(ptr)

Haha, you've missed the issue. The question is what does the system do when someone overrides the builtin allocator functions, but does not override all of them. You are absolutely correct that as a developer you can have your process override the allocator functions, and that is in fact what TF has done. The problem is that they have not overridden all of the allocation functions, and so they're crashing due to mism…

Post by exabrial » Tue, Apr 25, 2023, 3:14 PM UTC

exabrial wrote: post #51

I thought TF2 was pretty much 100% hacked... like no legit non-hackers playing except at LAN parties.