Fix compilation for targets that don't have AtomicU64.

[flaviojs]

Connections
Fixes #5997

Description
AtomicU64 is not available in PowerPC 32-bit and other targets.
When that happens, replace it with the implementation in portable-atomic.

Please backport this to older versions, in my case I need it in v0.20 for MartyPC.

A binfmt-based solution with a ppc32 chroot takes 20-30 times longer to compile so I don't recommend it in CI.
I don't have enough knowledge to try a cross compile that only uses binfmt for testing.
At minimum, I recommend adding a simple "can compile" test with a ubuntu runner to avoid bit rot:

rustup target add powerpc-unknown-linux-gnu
cargo build --lib --target powerpc-unknown-linux-gnu

Testing
I do not have a GUI setup in my vm so testing was limited.

I used a linux x86_64 host and a PowerPC 32-bit qemu vm with ArchPOWER.
This is the command line that my script invokes to start the vm in normal runs:

sudo \
    qemu-system-ppc \
    -name vm-ppc \
    -m 1536M \
    -k pt \
    -M mac99,via=pmu \
    -cpu g4 \
    -virtfs local,path=shared,mount_tag=shared,security_model=passthrough,multidevs=remap \
    -net nic \
    -net user,hostfwd=tcp::2222-:22 \
    -drive id=hd,format=qcow2,discard=unmap,detect-zeroes=unmap,file=archpower-vm-ppc.qcow2 \
    -drive id=cd,readonly=on,media=cdrom \
    -prom-env 'boot-device=hd:,\grub' \
    -nographic

These naga tests fail:

• back::msl::test_error_size
• back::msl::writer::test_stack_size
• proc::typifier::test_error_size

It seems to be related to the difference in pointer size and safe to ignore.
I recommend adding linux x86 to the CI, maybe with Alpine Linux:

jobs:
  linux-x86:
    name: Linux (x86)
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Setup x86 chroot with Alpine Linux and install dependencies
      uses: jirutka/setup-alpine@v1
      with:
        arch: x86
        packages: >
          build-base
          other-dependencies

    - name: Do stuff
      shell: alpine.sh {0}
      run: |
        echo "do stuff in a 32-bit environment"

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target powerpc-unknown-linux-gnu
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[ErichDonGubler]

One concern from Mozilla's end here is that cfg filtering might not eliminate portable-atomic as a dependency. Mozilla has to vet every dependency not written by Mozillians for usage of unsafe, and for a crate like portable-atomic, we suspect that that would be a high amount of effort.

CC @glandium for guidance here; I'm going to check to see if consuming this PR causes problems.

Clicking Request changes not because I think this PR is bad (it's so neat that the community cares about targets like these!), but because Mozilla needs to do some homework here before announcing a disposition on merge-ability.

[ErichDonGubler]

☝🏻

[cwfitzgerald]

I will note that we can put it behind a feature still, so mozilla does not get it in tree at all.

[ErichDonGubler]

Just tested and confirmed locally that this would add portable-atomic to Firefox's lockfile. I think @cwfitzgerald's idea to use a feature is a good one; maybe you could do that, @flaviojs?

[flaviojs]

Tried it, and it still appears in the wgpu Cargo.lock when it's behind a feature. I expect the same to happen for mozilla.

Using a feature also changes the scope of the change from "leave everything that is working untouched, add support for extra targets" to "replace AtomicU64 if the user wants, even for targets that already work".
This adds an extra variable "does it use portable-atomic?" to bug reports/maintenance for targets that already work.

I think it is better to not use a feature and just wait for mozilla to do it's homework.

[cwfitzgerald]

Sorry this was poorly explained by us as we actually have a we should have a feature inside wgpu-core for portable atomics. Then the wgpu crate will take that dependency on unconditionally.

Making it a feature like this is actually will add it to our Cargo.lock but not Mozilla's because of how lock files work.

I think it is better to not use a feature and just wait for mozilla to do it's homework.

This is a pretty fundamental thing of how cargo-vet and resolution work, so any extra dependencies, especially unsafe ones, create a large vetting burden on those who have strict protections against supply chain attacks.

[flaviojs]

I don't fully understand (lack of domain knowledge), but if it indeed fixes the problem then sure I'll do it.

Not sure what would be a good name so I set it to the name of the dependency.
The feature portable-atomic affects wgpu, wgpu-core, and wgpu-hal.

[cwfitzgerald]

We've agreed that we're going to take this once we validate that portable-atomics isn't pulled into mozilla-central.

Will re-review this soon.

[cwfitzgerald]

There is a few more tweaks needed on the cfgs - if anything is unclear just shout :)

Working on getting clearance that this won't affect mozilla central.

[ErichDonGubler]

I can confirm that, when consumed, the current contents of this PR do not add another dependency for Firefox. In that way, LGTM! I'll leave the rest of review to @cwfitzgerald.

[cwfitzgerald]

Thanks!