Fedora 38 LLVM vs. Team Fortress 2

Post by mariusor » Mon, Apr 24, 2023, 8:57 PM UTC

zamalek wrote: post #14

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…

> You can find many issue threads on GitHub reporting client freezes and crashes. The fact that these are happening does not necessarily mean the client is getting worse. For example, it could mean that more people are installing Steam for Linux. There is no baseline to say it's getting worse, because nobody opens an issue saying "all working here." In my experience, the only issue I have on Wayland is this: https://…

Post by sosodev » Mon, Apr 24, 2023, 9:01 PM UTC

Arnavion wrote: post #22

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 run Steam in a Docker container of Ubuntu 22.04 for reasons like this. Also my actual system isn't polluted with 32-bit libs, Steam can't rm-rf my home directory and games can't steal files from my home directory (homedir inside the container is a separate directory on the host), and access to X and dbus is restricted (dbus socket not forwarded, X socket is from a nested Xephyr instance) so nothing can be stolen fr…

Post by viraptor » Mon, Apr 24, 2023, 9:01 PM UTC

olliej wrote: post #18

viraptor wrote: post #13

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) But as the other comment mentioned - it should be a problem for tf2 in the first place since that's not the behaviour they're after.

> 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…

    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)

Post by sosodev » Mon, Apr 24, 2023, 9:08 PM UTC

zamalek wrote: post #24

sosodev wrote: post #19

Earlier quoted context omitted.

True, I don't have enough data to really make that claim. I can say that my own hardware hasn't changed in ~4 years and I've been using Steam for Linux since I built this machine. It's only within the last year or so that I started having major issues with the client. > there is nothing special about the steam deck How is first party support for the hardware and software stack "nothing special"? > If it is bjorked th…

> How is first party support for the hardware and software stack "nothing special"? Because the vast majority of that stack (the kernel, GPU driver, window manager, and so forth) has nothing to do with Valve. They might contribute drivers to the kernel (I'm not sure if they actually do - I would expect AMD to be doing that), but otherwise it's an Arch-based distro with the same Steam client and Proton runtime that ev…

Post by olliej » Mon, Apr 24, 2023, 9:14 PM UTC

jenadine wrote: post #9

olliej wrote: post #5

Earlier quoted context omitted.

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…

That's not sound in general, but it is "probably" going to work for this specific case because the previous build was build with allocator that did not support this alignment, meaning that they did not need extra alignment. This is pretty rare actually. And you had anyway to use a custom allocator already with previous C++ versions to make it work.

    someSystemLibrary.so`someFunction:
      alignedThing = ::operator new(size, alignment)
      ...
      i_dunno_dma_memcpy_or_something(a, somewhere else)
      ...
      ::operator delete(a)