Add basic NetBSD support

[0323pin]

closes #8541
replaces #8679

Tests:
Summary [ 149.522s] 469 tests run: 463 passed, 6 failed, 0 skipped FAIL [ 0.095s] naga::naga snapshots::convert_snapshots_spv FAIL [ 0.387s] wgpu-benchmark::bench/wgpu-benchmark Computepass Encoding FAIL [ 0.386s] wgpu-benchmark::bench/wgpu-benchmark Device::create_bind_group FAIL [ 0.378s] wgpu-benchmark::bench/wgpu-benchmark Device::create_buffer FAIL [ 0.389s] wgpu-benchmark::bench/wgpu-benchmark Renderpass Encoding FAIL [ 0.075s] wgpu-test::wgpu-validation api::instance::multi_instance::multi_instance

Connections
Link to the issues addressed by this PR, or dependent PRs in other repositories

When one pull request builds on another, please put "Depends on
#NNNN" towards the top of its description. This helps maintainers
notice that they shouldn't merge it until its ancestor has been
approved. Don't use draft PR status to indicate this.

Description
Describe what problem this is solving, and how it's solved.

Testing
Explain how this change is tested.

Squash or Rebase?

If your pull request contains multiple commits, please indicate whether
they need to be squashed into a single commit before they're merged,
or if they're ready to rebase onto trunk as they stand. In the
latter case, please ensure that each commit passes all CI tests, so
that we can continue to bisect along trunk to isolate bugs.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[0323pin]

FWIW running cargo clippy on NetBSD using Rust-1.91.1 built from source on a clone of wgpu main branch (trunk) where the latest commit is f558612, i.e. without my changes yields the same warning:

[...]
warning: variable does not need to be mutable
   --> wgpu-core/src/instance.rs:267:13
    |
267 |         let mut errors = HashMap::default();
    |             ----^^^^^^
    |             |
    |             help: remove this `mut`
    |
    = note: `#[warn(unused_mut)]` (part of `#[warn(unused)]`) on by default

warning: variable does not need to be mutable
   --> wgpu-core/src/instance.rs:268:13
    |
268 |         let mut surface_per_backend: HashMap<Backend, Box<dyn hal::DynSurface>> =
    |             ----^^^^^^^^^^^^^^^^^^^
    |             |
    |             help: remove this `mut`

    Checking rand v0.8.5
    Checking rand_xorshift v0.3.0
    Checking wayland-protocols-plasma v0.2.0
    Checking nanorand v0.8.0
    Checking spin v0.9.8
warning: this lint expectation is unfulfilled
   --> wgpu-core/src/resource.rs:878:59
    |
878 |                 #[cfg_attr(not(feature = "trace"), expect(clippy::collapsible_if))]
    |                                                           ^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unfulfilled_lint_expectations)]` on by default
[...]

So, this is unrelated to my changes. Is this platform specific?

[ErichDonGubler]

@0323pin:

• RE: unused_mut warnings: The reason that's firing is because Instance::create_surface_from_drm (compiling because NetBSD is a unix) marks those two variables as mut. The vulkan feature is not enabled, so no work is done to actually set those variables (and a surface creation error will unconditionally be returned). I'm not familiar with NetBSD as a platform; is it intended to expose that method? If so, we may need to add a #[cfg_attr(not(vulkan), expect(…))] attribute on those variable declarations (if that's intended) or add more logic specifically that sets those for NetBSD. If not, you'll need to adjust cfg to exclude it on NetBSD.
• RE: unfulfilled_lint_expectations: You can ignore this warning. Once our CI upgrades to a newer Rust version, we'll want to remove it, since the false positive that line is working around will have been fixed in the newer Rust.

EDIT: s/FreeBSD/NetBSD/, SMH at myself

[0323pin]

@ErichDonGubler thanks for the hints. NetBSD doesn't support Vulkan, only OpenGL. So, I would say it should be excluded.

I'll have a look at it tomorrow, need to get some sleep first.

[0323pin]

@ErichDonGubler May I request further pointers? I've changed wgpu-core/src/instance.rs to exclude NetBSD as we don't support Vulkan. I've done this doing the following at lines 254 and 929

    #[cfg(all(
        unix,
        not(target_vendor = "apple"),
        not(target_family = "wasm"),
        not(target_os = "netbsd")
    ))]

But, now clippy complains that:

error[E0599]: no method named `instance_create_surface_from_drm` found for struct `alloc::sync::Arc<wgc::global::Global>` in the current scope
   --> wgpu/src/backend/wgpu_core.rs:812:24
    |
812 |                 self.0.instance_create_surface_from_drm(
    |                 -------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
help: there is a method `instance_create_surface` with a similar name, but with different arguments
   --> /home/pin/Git/wgpu/wgpu-core/src/instance.rs:913:5
    |
913 | /     pub unsafe fn instance_create_surface(
914 | |         &self,
915 | |         display_handle: raw_window_handle::RawDisplayHandle,
916 | |         window_handle: raw_window_handle::RawWindowHandle,
917 | |         id_in: Option<SurfaceId>,
918 | |     ) -> Result<SurfaceId, CreateSurfaceError> {
    | |______________________________________________^

[ErichDonGubler]

@0323pin: You'll need to make similar cfg adjustments all the way up the call chain; you're the NetBSD expert here, so correct me if I'm wrong, but it seems your intention is to exclude drm (4) as a surface backend…unless you implement support for NetBSD's DRM system as a surface for OpenGL to render to, that is.

[ErichDonGubler]

Update from me here: Just waiting on the author to make progress. Excited to see it happen, but no rush. 🙂

[0323pin]

Update from me here: Just waiting on the author to make progress. Excited to see it happen, but no rush. 🙂

Lets take it by parts, shall we 🥲

Your earlier suggestion,

unless you implement support for NetBSD's DRM system as a surface for OpenGL to render to

got me thinking and, obviously this would be a much better solution. So, thanks for that.

Unfortunately, that's over my knowledge level. I don't have a degree in computer sciences, I have a degree in chemistry, statistical thermodynamics and a PhD in organic chemistry 🤣. I got into packaging software because I wanted an open source molecule drawing tool that would run on NetBSD, i.e. mostly by accident.

I have asked for help internally. I've been waiting for a reply. If I get none, I will go back to my original plan and try to fix what's left, I still want this fixed. Thanks for keeping this PR open for now.

[0323pin]

@ErichDonGubler I didn't get the expected help, so I went with the original plan, i.e. exclusion.

With some help from a LLM it is now clippy clean.
But, it seems that re-basing might be tricky after a few weeks of other changes. Let me know if you would like me to close this and open another PR on a more recent base.

[ErichDonGubler]

@0323pin: You need to rebase, so CI can actually run (and we can prove we're not accidentally regressing something), but you needn't make another PR; just force-set your branch locally to the new commit stack you want.

…or, at least, that's what I would say, if I wasn't going to refute the perceived difficulty of the merge conflict. I only needed to re-apply the cfg changes over the recent adjustment to the call to this.try_add_hal(hal::api::Vulkan, &instance_desc, telemetry);, which had some arguments adjusted.

I've forced-pushed with a couple of fixes. The tip of the PR is 6000935, which I think is also necessary for wgpu-deps-windows-linux-android. After that, let's merge!

[0323pin]

@ErichDonGubler Just so I don't do anything stupid now ...
You are saying that I should do the following:

git pull -r                                                  # to accept the changes you pushed
git remote -v                                                # to check my fork
git remote add upstream https://github.com/gfx-rs/wgpu.git   # add upstream
git fetch upstream                                           # probably unnecessary but, just in case
git rebase upstream/trunk                                    # to actually rebase
git push --force-with-lease                                  # to push everything back to my fork

Is this correct?
If there are conflicts while rebasing, I should after fixing them:

git add <files>
git rebase --continue

before force pushing.
Did I get it right?

[0323pin]

@ErichDonGubler I hope I've done this correctly. At least all checks were successful.