feat: add WebGPU (wgpu) rendering backend (Linux x64)

[yuiseki]

Launch Checklist

• Confirm changes do not include backports from Mapbox projects — this PR only uses MapLibre Native's public mbgl::* API plus this crate's own bridge code.
• Briefly describe the changes (below).
• Link to related issues (below).
• Before/after visuals — N/A, no visual change; this adds a headless backend.
• Write tests — adds a webgpu CI lane that links and renders against the released amalgam.
• Document changes to public APIs — GeoJson::to_json_string is temporarily removed (see below).
• Post benchmark scores — N/A.
• Add a CHANGELOG.md entry — skipped; this is an experimental PR (happy to add before merge).

What this does

Adds a webgpu feature that renders through MapLibre Native's wgpu-native backend, consumed as the prebuilt Linux x64 core amalgam (the other targets do not ship a wgpu amalgam yet).

Background: I added the upstream support for producing that amalgam in maplibre/maplibre-native#4220 (merged). That alone turned out not to be enough to consume it from here, so this PR adds the downstream pieces:

• build.rs: a WebGPU graphics API behind the webgpu feature, selecting the ...-wgpu.a amalgam and linking the system libraries it pulls in (uv, GL, X11).
• GeoJSON bridge: switch from mapbox::geojson::parse to the public mbgl::style::conversion::parseGeoJSON.
• CI: a Linux x64 webgpu lane (library + integration tests) that links and renders against the released amalgam.

Why the GeoJSON change (the main point)

The core amalgam is built with armerge --keep-symbols 'mbgl.*', which intentionally localizes every non-mbgl symbol. So mapbox::geojson::parse / stringify are hidden, and the amalgam will never export mapbox::*. Reaching into the bundled geojson-cpp from this crate therefore cannot link against the precompiled amalgam.

So I would like to propose: stop depending on mapbox/geojson.hpp, and use mbgl/style/conversion/geojson.hpp instead. parseGeoJSON is public (mbgl::*, exported), so the bridge links cleanly against any backend's amalgam, with no vendoring.

About to_json_string / stringify

These were only used in tests. MapLibre Native currently exposes no public mbgl::* GeoJSON serializer, so I commented them out (with TEMP(webgpu amalgam) markers, trivial to restore). I intend to open a small separate PR to maplibre/maplibre-native adding a public mbgl GeoJSON stringify; once that ships, I will restore to_json_string cleanly.

No rush to merge

This is an experimental PR, and it is totally fine to hold off merging. The first goal is to show, via this PR's GitHub Actions, that the WebGPU path links and renders. I am happy to discuss the approach (especially the GeoJSON direction) before anything lands.

Validation

Verified locally on Linux x64 (NVIDIA + llvmpipe): the library and integration tests link against libmaplibre-native-core-amalgam-linux-x64-wgpu.a and render with 0 unresolved wgpu* symbols.

Related

• Bundle wgpu-native into Linux WebGPU amalgamation maplibre-native#4220 — upstream amalgam support (merged)
• feat(core): Add public stringifyGeoJSON to mbgl::style::conversion maplibre-native#4345 — upstream stringifyGeoJSON support

[CommanderStorm]

@Murmele @yuiseki would it be possible to collaborate? 😉
Lets get the following PR merged, or is this approach better?

• feat: migrate continous mode to Wgpu textures #143

[Murmele]

@Murmele @yuiseki would it be possible to collaborate? 😉 Lets get the following PR merged, or is this approach better?

* [feat: migrate continous mode to Wgpu textures #143](https://github.com/maplibre/maplibre-native-rs/pull/143)

My PR handles the case that you can use the wgpu textures within rust. With this PR you still have to get the texture down on the CPU and then reusing it. Basically same as we have right now for vulkan, ...
I don't have anything against merging mine first ^^

[CommanderStorm]

I don't have anything against merging mine first ^^

You know you have write rights? Whenever you are ready and think it is done 😉

[Murmele]

I don't have anything against merging mine first ^^

You know you have write rights? Whenever you are ready and think it is done 😉

Haha yes. 😄

[yuiseki]

@CommanderStorm @Murmele Thank you both for your comments! And of course I’d love to collaborate!

Those comments helped me catch up on the context.

I understood @Murmele has done a great job about wgpu in #143 , awesome!
I think #143 is the correct answer for zero-copy.

I think amalgam is still useful for headless applications that don't require building from source.

Now this PR has big conflicts 😆 , so I will close this and re-open new PR that focus consume amalgam from current main branch 👍

Thanks again for your comments! I think I’m on the right track now!

[CommanderStorm]

Thanks for working on the amalgam usecase, I have somewhat let that part slide a bit ❤️