Workaround xcode misreporting ray tracing support

[mate-h]

Connections
Fixes #9756

Related originating PR (no hard dependency): #9081

Description

On a CaptureMTLDevice calling supportsRayTracing causes a fault. same problem as hasUnifiedMemory. For Solari or more generally RT apps we still want to use xCode capture.

Since this is a boolean defaulting to false would effectively disable RT frame capture capability on metal devices running Xcode debugger.

So when the API path isn't safe, we fall back to the same source as elsewhere in the file, that is the Metal GPU features table.

Apple documents "Ray tracing in compute/render pipelines" from MTLGPUFamilyApple6 in Metal Feature Set Tables, "Metal feature availability by GPU family," with footnotes 9 and 10. A13 is the first Apple6 GPU in the Apple silicon mapping table.

Testing

Tested with repro steps in the linked issue.

Squash or Rebase?

Squash

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[andyleiserson]

The device_class_responds_to stuff was added to avoid tripping objc2 debug assertions when running against the capture device. So that part can be removed if we're not going to use it with the capture device anyways. But I'm also not thrilled about having both device_class_responds_to and is_capture_mtl_device for the same purpose.

Since the Metal feature set tables say:

Some GPU devices in the Mac2 family support ray tracing in compute pipelines. You can check an individual GPU’s support for this feature by inspecting its MTLDevice.supportsRaytracing property at runtime.

... maybe the thing to do here is:

metal4
    || (family_check && device.supportsFamily(MTLGPUFamily::Apple6))
    || device_class_responds_to(device, sel!(supportsRaytracing))
                        && device.supportsRaytracing()
                        && device_class_responds_to(device, sel!(supportsRaytracingFromRender))
                        && device.supportsRaytracingFromRender()

There's also the issue of ray tracing compute vs. render pipelines which determines whether support starts in Metal3 or Metal4. Maybe somebody more familiar with the wgpu ray tracing feature can suggest how to handle that.

One other idea... we could do an is_capture_mtl_device check on adapter creation, and if so, print a warning that feature detection is degraded, referencing a wgpu issue that captures the known problems.