[bgfx] New dependencies following webgpu backend

[Robin WILS (robinwils)]

Hi, I am trying to update bgfx's port to 1.161.9495-578 in my project's vcpkg_overlay but having a dependency problem.
The new webgpu backend uses dawn's tint compiler (in shaderc). My first attempt to simply use the 3rd party dawn from bgfx fails because tint includes spirv-tools internal source headers, which are not present in vcpkg bgfx port.

I was wondering what was the best way of handling this. Dawn vcpkg port does not seem to install tint, and gets the spirv-tools internal sources by downloading them directly it seems. Should the same be done for bgfx ? Or maybe an independent tint vcpkg port ?

Thanks in advance,

[RKS (rksharma-owg)]

I would avoid creating a standalone tint port as the first step here. Tint is tightly coupled to the exact Dawn revision that consumes it, and the current vcpkg Dawn port handles that by fetching pinned SPIRV-Headers and SPIRV-Tools sources into Dawn’s source tree. That is important because the build needs internal headers, not just the installed public SPIR-V headers.

For an overlay updating bgfx, I would mirror the upstream bgfx/Dawn revision relationship and keep the matching third-party sources pinned in the portfile, using vcpkg helpers such as z_vcpkg_from_github_to_path or the equivalent existing Dawn pattern. Do not fetch an unpinned main branch, and do not assume the separately installed spirv-tools package exports the internal source layout that Tint expects.

A separate vcpkg tint port would make sense only if there is a stable, reusable install/export boundary for that exact Tint version. If Tint is still built as part of Dawn’s shader toolchain, vendoring the pinned sources alongside the consumer is the more consistent approach with the current port. I would also update the bgfx port’s dependency graph and CMake patch together, then verify both the normal library build and the tools/shaderc feature rather than only checking that configuration succeeds.

[Robin WILS (robinwils)]

For an overlay updating bgfx, I would mirror the upstream bgfx/Dawn revision relationship and keep the matching third-party sources pinned in the portfile, using vcpkg helpers such as z_vcpkg_from_github_to_path or the equivalent existing Dawn pattern. Do not fetch an unpinned main branch, and do not assume the separately installed spirv-tools package exports the internal source layout that Tint expects.

I was thinking of doing this at first, but then why would we go through the trouble of doing this in a 3rd party dir from vcpkg ? The 3rd party sources are already present in bgfx source code. The devendoring PR #47441 removes them, but we might as well keep them for the tint dependency in shaderc, since we can't easily have that with a vcpkg port. This would mean keeping the spirv-tools 3rdparty from bgfx that is currently removed and keep the other removals intact.
Also, I said that I am trying this in my custom overlay, but I might want to push that to vcpkg if it is acceptable.

[RKS (rksharma-owg)]

You're right: if the pinned bgfx release already contains the matching sources, fetching them again is unnecessary. My earlier recommendation was too broad, especially about upstream acceptance. Also, z_vcpkg_from_github_to_path is a function defined locally in Dawn's portfile, not a general vcpkg helper.

For your overlay, retaining the inputs needed by Tint while keeping the other de-vendoring changes is a reasonable approach to test. In bgfx.cmake v1.161.9495-578's Tint target, those inputs include Dawn, SPIRV-Tools' source/public/generated headers, and SPIRV-Headers. Tint's parser actually includes source/opt/build_module.h and other private optimizer headers. Retaining directories alone isn't enough: the updated CMake patch also needs to preserve the Tint target and shaderc's link dependencies. If you keep using the packaged SPIRV-Tools library, check compatibility with those bundled private headers; they aren't a stable public interface.

For an upstream PR, though, the maintainer guide explicitly discourages vendored dependencies. Dawn's existing source packaging doesn't establish that restoring them in bgfx will be accepted. I'd first seek maintainer agreement here on either a narrowly scoped private dependency arrangement for shaderc, or reusable Tint library targets through Dawn. The current Dawn port does have tint-tools, but that installs the executable; TINT_ENABLE_INSTALL=OFF means it doesn't supply the Tint library integration this bgfx build needs.

For validation, I'd cover both the library build without tools and bgfx[tools], including an actual shaderc compilation that exercises its WGSL path. I've checked the pinned sources and current port policy, but haven't built your overlay, so I can't yet say the selective-retention patch works.