Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fedora 38 LLVM vs. Team Fortress 2

airlied.blogspot.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Fedora 38 LLVM vs. Team Fortress 2

#31

Post by Asooka »

olliej wrote: post #5
amluto wrote: post #3

It should be straightforward to make a little LD_PRELOAD shim to implement the new operator new on top of old overloads and thus restore proper functioning. It would be a gross kludge, though.

I'm not sure that's sound. You can't just redirect an aligned new to the unaligned operator new as you may get unaligned result. It _sounds_ like what is happening is a = ::operator new(some size, some alignment) ... ::operator delete(a); where delete is dropping the align_val_t parameter that would guarantee it hits the same allocator family. There are a variety of ways this can happen, and let's just take it as giv…

The C interface for aligned memory allocation is aligned_alloc(). The returned pointers are always freed with free(). So what is probably happening is that aligned new calls aligned_alloc(), and then aligned delete simply calls the regular delete, expecting to end up in free(), which by design should work with both kinds of pointers.

I think the problem here is partly with the implementation of aligned new/delete. Since one is free to override only the old versions, the ones supplied by the standard library should make sure not to fall back to functions that may be partially overriden.

Re: Fedora 38 LLVM vs. Team Fortress 2

#32

Post by admax88qqq »

Unfortunately this is exactly the type of stuff that makes supporting commercial apps on linux a nightmare. Weird crashes due to weird linking of system libraries.

Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonical version of every library systemwide. This leads to these sorts of issues.

Windows gets around it by letting applications put the DLLs they care about beside the executable, and having it check there first by default.

Re: Fedora 38 LLVM vs. Team Fortress 2

#33

Post by admax88qqq »

zamalek wrote: post #30
mariusor wrote: post #21

Earlier quoted context omitted.

> There is nothing special about the Steam Deck. It's just another Linux machine. That's not true. It's a read-only linux on a fixed hardware platform, which is a vaaastly different beast than the myriad of hardware/software combinations that exist out there in the wild.

> It's a read-only linux on a fixed hardware platform I have heard that argument about macOS a lot, and this is nothing like that. There isn't some "special sauce er... Source" that they apply to their platform. It's just GPL Linux. They may have avoided bad decisions like relying on NVIDIA for Linux gaming, but that's hardly the level of ownership that you see with other vertical integrations. If I use an AMD CPU (o…

I feel like there is a gap in understanding of how commercial software deployment goes.

When you have a platform like Steam Deck, it's the platform that gets tested by QA, and the platform that most of your devs are building for every day.

Re: Fedora 38 LLVM vs. Team Fortress 2

#34

Post by mariusor »

zamalek wrote: post #30
mariusor wrote: post #21

Earlier quoted context omitted.

> There is nothing special about the Steam Deck. It's just another Linux machine. That's not true. It's a read-only linux on a fixed hardware platform, which is a vaaastly different beast than the myriad of hardware/software combinations that exist out there in the wild.

> It's a read-only linux on a fixed hardware platform I have heard that argument about macOS a lot, and this is nothing like that. There isn't some "special sauce er... Source" that they apply to their platform. It's just GPL Linux. They may have avoided bad decisions like relying on NVIDIA for Linux gaming, but that's hardly the level of ownership that you see with other vertical integrations. If I use an AMD CPU (o…

Sure, a linux machine is made out of just a CPU and a GPU. Even if that would be the case, what about the software combinations that can exist and that the SteamDeck simplifies?

In the gamedev world I heard a lot of people not wanting to support linux because they never know which glibc version to support, which mesa version to support, which hardware GPUs to support, which graphical API to support, etc.

Cutting down that matrix (and I just mentioned the most egregious examples) to only one element is invaluable in ensuring your users have a bug free experience.

Re: Fedora 38 LLVM vs. Team Fortress 2

#35

Post by gabcoh »

admax88qqq wrote: post #32

Unfortunately this is exactly the type of stuff that makes supporting commercial apps on linux a nightmare. Weird crashes due to weird linking of system libraries. Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonic…

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?

Re: Fedora 38 LLVM vs. Team Fortress 2

#36

Post by olliej »

nneonneo wrote: post #28
olliej wrote: post #18

Earlier quoted context omitted.

> If you don't mind wasting a bit of time, you could forward size+alignment to the allocator, return the aligned version and keep a record of aligned-to-allocation mapping. (For freeing later) I'm unsure what you're proposing here - the only methods you know in the replacement allocator are operator new(size_t) and operator delete(void ). The two possible failure paths are: a = ::operator new(some size) ... ::operato…

The latter suggestion assumes that there’s enough entropy in the allocation process to make this work. But that’s not guaranteed! Suppose that your allocator doesn’t pad allocations (e.g. because it uses a bitmap), and that it only guarantees 0x10 alignment. If the top of the heap happens to be unaligned with respect to your desired alignment (e.g. address ends in 0x10 when you want 0x20 alignment), you might wind up…

> The latter suggestion assumes that there’s enough entropy in the allocation process to make this work. But that’s not guaranteed!

Oh absolutely, there's no guarantee it's ever aligned: the allocator could wrap an aligned allocator but include a pointer sized prefix (a la array allocations) so you would be _guaranteed_ to never be more than pointer size aligned :D

As you say versioning and namespacing is super problematic, but I'm not sure they'd even work here.

At it's core the problem is that some code is compiling with the knowledge it has aligned allocations, so can assume alignment, and the some parts are not. There are a bunch of options that ensure that the allocator is consistent, but they devolve to either ignoring the new+delete overrides, or having the aligned allocators detect the override and forward to unaligned allocators while hoping nothing depended on correct alignment.

Re: Fedora 38 LLVM vs. Team Fortress 2

#37

Post by mlyle »

zamalek wrote: post #30
mariusor wrote: post #21

Earlier quoted context omitted.

> There is nothing special about the Steam Deck. It's just another Linux machine. That's not true. It's a read-only linux on a fixed hardware platform, which is a vaaastly different beast than the myriad of hardware/software combinations that exist out there in the wild.

> It's a read-only linux on a fixed hardware platform I have heard that argument about macOS a lot, and this is nothing like that. There isn't some "special sauce er... Source" that they apply to their platform. It's just GPL Linux. They may have avoided bad decisions like relying on NVIDIA for Linux gaming, but that's hardly the level of ownership that you see with other vertical integrations. If I use an AMD CPU (o…

> It's just GPL Linux.

"Just" GPL Linux encompasses myriad library versions, kernel versions, driver versions and varied hardware.

> I feel like there is a gap of understanding how a HAL works here.

Just because you have a HAL doesn't mean that you don't get different behavior and crashes with different numbers of CPUs/concurrency or other hardware beneath. Modern GPUs are also pretty complicated beasts, and assuming that's fully abstracted is a mistake.

And this all leaves aside the myriad of other problems you can have with the ensemble of software running on the machine that interacts with the game (directly or indirectly).

Being able to test and make one restricted platform work well is a far different beast than covering the huge mass of variation users create on their own machines.

Re: Fedora 38 LLVM vs. Team Fortress 2

#38

Post by PlutoIsAPlanet »

IceWreck wrote: post #6

Isn't this the reason why people recommend using the flatpak version of Steam ?

Yes, especially on Fedora.

This isn't something Fedora is doing wrong, unfortunately some games build against older libraries or are built against Debian/Ubuntu and the Flatpak runtimes generally have better compatibility.

Re: Fedora 38 LLVM vs. Team Fortress 2

#39

Post by bravetraveler »

gabcoh wrote: post #35
admax88qqq wrote: post #32

Unfortunately this is exactly the type of stuff that makes supporting commercial apps on linux a nightmare. Weird crashes due to weird linking of system libraries. Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonic…

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?

I was thinking/wondering this myself. Not to reinvent the wheel - more toss an idea around, but a 'venv for LD_PRELOAD' sounds like it'd deal with this pretty handily

Not... in a way I'd use as a distribution/release maintainer. Probably as an administrator [of my LAN]

Re: Fedora 38 LLVM vs. Team Fortress 2

#40

Post by pjmlp »

ho_schi wrote: post #20
sosodev wrote: post #7

It's unfortunate but the Steam experience on Linux seems to be progressively getting worse (outside of Steam Deck ofc). The Steam client is often borderline unusable for Linux users. You can find many issue threads on GitHub reporting client freezes and crashes. It seems like a big part of the issues is a lack of maintenance. TF2 would actually run better on Linux via Proton but VAC isn't enabled so you can't join th…

I can’t see how native Linux support is getting worse. Linux users are good at bug reporting. Maybe some developers should care more about compatibility. And yes, especially the heterogeneous setups used by some makes support difficult. I’m worried that Valve puts too much resources into Proton (derivate of WINE) instead of tooling for native ports. Yes, Proton is needed to provide initial compatibility. But Proton i…

Game studios already know Linux distributions quite well on the server, and most AAA games on Android are basically only using the NDK, meaning ISO C and C++, OpenGL ES, Vulkan, OpenSL.

Besides that, PlayStation OS is based on FreeBSD. Even if the 3D API is different, it is just yet another backend.

They don't port them, because the QA and support aren't worth the sales, that is about it.

Post reply on HN