Thanks for the patch, @xctan! I've added you to the "Contributors" group, so the next time you upload a patch, it is built by our CI.
I can't comment on the patch itself, but I can ask you to upload it with context and add yourself to the credits. :)
(See https://trac.wildfiregames.com/wiki/SubmittingPatches#Makingsomechanges.)

Is this ment to be applied on top of D4634?

The dw-cas is likely used in boost::lockfree::queue and we try to remove boost as a dependency.

We don't use 16byte atomics directly, I think it might be under the hood of boost::lockfree::queue. I'm also wondering why it's not linked automatically (by detecting standard library usage)?

Possible references:

• https://github.com/EttusResearch/uhd/issues/410
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

In D5127#217994, @phosit wrote:

Is this ment to be applied on top of D4634?

The dw-cas is likely used in boost::lockfree::queue and we try to remove boost as a dependency.

Yes, for riscv64 support.

In D5127#217996, @vladislavbelov wrote:

We don't use 16byte atomics directly, I think it might be under the hood of boost::lockfree::queue. I'm also wondering why it's not linked automatically (by detecting standard library usage)?

Possible references:

• https://github.com/EttusResearch/uhd/issues/410
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

Previously before inline atomics were added to riscv-gcc, --as-needed -latomic --no-as-needed is included in the builtin spec for pthread, which in turn automatically detects its usage. But on riscv64 doubleword atomics can't be lockfree (i.e. no instruction support in rv64gc ISA), so the compiler can't inline these operations either. The library libatomic internally uses a table of locks to ensure atomicity.

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/7285/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/8374/display/redirect

In D5127#218003, @xctan wrote:

Yes, for riscv64 support.

Sorry for the long reply. Could you upload your system_info and userreport_hwdetect with your hardware? Also how smooth is it?

We'd like to support riscv64 but we don't have active people to test it.

From the ticket on Twitter, I'm not sure but I think the hangs are caused by the GC (Similar issue on RPI4):

In D5127#219402, @Stan wrote:

From the ticket on Twitter, I'm not sure but I think the hangs are caused by the GC (Similar issue on RPI4):

Is there a more powerful combination with riscv64?

There are some options https://milkv.io/ but I don't know which one was used.

In D5127#219399, @vladislavbelov wrote:

Sorry for the long reply. Could you upload your system_info and userreport_hwdetect with your hardware? Also how smooth is it?

I haven't thoroughly tested the game on my RISC-V boards yet. Their integrated Imagination GPUs have poor driver support. So, I'm waiting for new boards with PCIe slots, where a decent GPU with proper OpenGL support can be attached.

In D5127#219407, @vladislavbelov wrote:

Is there a more powerful combination with riscv64?

Sophgo is going to launch a new SoC SG2380 with more powerful SiFive cores in a few days.