Does Unity expose what Metal API its using?
Version 1, 2 or 3 etc?
Something I can programmatically check.
there is no such thing as “metal API” version (while this numbering is not exactly marketing - by itself it is not very well defined). You should directly check for what is needed instead
1 Like
Whilst technically correct, when the API is added as a suffix, there are versions of Metal, which is what this question is trying to ask. Probably.
Could you answer that question: Which version of Metal?
Could you answer that question: Which version of Metal?
i did answer:
You should directly check for what is needed instead
As Alexey is saying, “version N” may support different subsets depending on the hardware available. It doesn’t seem to be like GL where the software is a fallback for missing hardware. It sucks, because it’s not too fun having to write a list of things like “doesn’t return an error when attempting quad-scoped permute operations” on your app’s Minimum System Requirements.
1 Like
On behalf of the world of more considered peoples, I apologise for the second guessing going on above. I think it’s about avoidance.
Near as I can tell, Unity is using version 2 of Metal, and nothing of the wonders of Metal 3, despite it providing all sorts of means to do better on Mac, iPhones, iPads, Apple TVs and now VisionOS. hence the reticence, I suppose.
But I think the real source of touchiness is that they’re likely not upgrading either the editor for Silicon, nor the builds for VisionOS, etc… because they’ve instead decided to rely on a bridge (of some sort) to Apple’s Materials/Shaders rather than port their own and give us an ability to ShaderGraph or HLSL our ways to excellence in the new Virtual Realities of ARKit and RealityKit.
Would love nothing more than to be able to make Metal Shaders in Unity… but that’s not going to be possible, for VisionOS, probably because they’ve stalled at Metal 2.
Near as I can tell, Unity is using version 2 of Metal, and nothing of the wonders of Metal 3
but that’s not going to be possible, for VisionOS, probably because they’ve stalled at Metal 2.
do you realize that what you are saying doesn’t make any sense? There is no such thing as “using version 2 of metal”. What exactly are you missing?
Would love nothing more than to be able to make Metal Shaders in Unity…
there is some support
iOSNativeCodeSamples/Graphics/MetalNativeShader at 2019-dev · Unity-Technologies/iOSNativeCodeSamples · GitHub
but again - this is limited because there is no a lot of demand for this
I’m going to guess two things, from the above:
- You don’t own any Apple gear, nor appreciate their ways
- You’re not familiar with “the chicken and the egg” metaphor
Looks like there are GPU families and there is one specifically for Metal3 feature set.
https://developer.apple.com/documentation/metal/mtlgpufamily
Given Apple defines what features exist in Metal 1,2,3 it seems like a enum could be defined (but maybe Metal 1,2 not so much?)
I’ve done work with native graphics APIs such as D3D9,10,11,12 OpenGL, GLES1,2,3 Vulkan etc for years. But have never done native Metal, so I’m a little more fuzzy here.
Seems like Apple is doing something akin to D3D11,12 features levels but more complex.
Anyway thanks for answer.
1 Like
Looks like there are GPU families and there is one specifically for Metal3 feature set.
MTLGPUFamily | Apple Developer Documentation
yeah it was added in xcode 14.smth
you can totally use it in native plugin - but the question remains - why exactly this needs to be checked?
Given Apple defines what features exist in Metal 1,2,3 it seems like a enum could be defined
so on one hand we can go combing through apple marketing material to determine what is “Metal 2” or we can ask what exactly do you need to be checked (that is not yet available in our api) and why?
No reason outside simplifying graphic tier levels maybe.
I’m making a custom render pipeline and thought it might come in handy later. But seeing as how they’re doing stuff probably doesn’t matter.
Ray Tracing?
Although I believe I already know the answer.
No reason outside simplifying graphic tier levels maybe.
oh that’s actually fair: “metal level 3” is kinda like “performant hw”, but yeah - i would say adding native plugin will be easier (note to self: check if macos trampoline supports ios-like “just add this file to project”)
Ray Tracing?
but
Unity - Scripting API: SystemInfo.supportsRayTracing
sure currently “unity metal” does not support ray tracing (not implemented on our end)
Metal 3 is a big move on and up. It’s like DirectX 11 and 12 coming to all of Apple’s last few years of products. And Apple’s getting serious about games on Mac, too.
From last year’s Developers Conference Videos: Discover Metal 3 - WWDC22 - Videos - Apple Developer
Metal doesn’t work like modern DirectX. For a hardware device to advertise support for a tier of DirectX it has to support a minimum set of features. Metal doesn’t have that requirement. Metal 3 supports devices as far back as 2017 which means just looking at the main API version won’t tell you what features a device has.
Well this actually is more fragmented even in D3D12 than one might imagine.
For example on 4th gen Intel GPUs RWTextures don’t work in D3D12. While they do work in D3D11.
And D3D11 has features levels that go all the way down to 9.1 and those hardware sets need their own hardware CAPS checked.
btw does Unity have a way to detect if pixel-shader thread locking is supported in Metal? I know this isn’t supported in Metal 1 or 2. But is it supported in Metal 3? Its required for OIT (aka Order Independent Transparency) effects.
1 Like
But is it supported in Metal 3? Its required for OIT (aka Order Independent Transparency) effects.
i dont think there is “pixel-shader thread locking” in metal. As far as i understand they want to do this with image blocks
Implementing Order-Independent Transparency with Image Blocks | Apple Developer Documentation
and the problem here is that we are absolutely not sure how to implement the support for this in a “sane way”
1 Like
Given your new partnership with Apple for VisionOS, do you think you could find someone over there (at Apple) to help you with this?
I’d love to see DOF recognise transparency. That’d be another game changer.
Man what the heck Apple. Just give us pixel locking control.
So they want you to partition tile memory and then hack around that with with a limited number of layers defined by “kNumLayers” ? If this is only 4 thats not nearly enough for OIT to be useful in almost any context. This also seems to only be for forward rendering which also isn’t useful as I’m making something I’m calling Deferred+ where transparent objects are deferred lit just like opaque ones are using ArrayTextures.
However to support this in Unity though you maybe would need to have a Unity RenderTexture desc store data about what this “RenderPassDescriptor” will need as RenderTextures are usally part of this state in the pipeline anyway. Then this allows a Unity script to set the custom values as needed. Now just some minor HLSL updates to support “TransparentFragmentStore” type. Seems like this approach might work with Unity to support the feature?
The fact GPUs from 2007 with D3D11 support pixel locking yet Apple still wont support this feature is just pathetic at this point. Even for CAD software this puts Apple hardware way behind. Absolutely unexpectable Apple.
If Unity has any weight with Apple I would push them to update their dumb drivers to support pixel locking (if the hardware is able to do this).
If “kNumLayers” can be more than 4 and you can also write out to an Array-RWTexture it might be possible to use to replicate this on Apple hardware. Maybe you can just not write out to the tile memory at all and just use this as the alternative to pixel ordering.
If so, it does seem like a feature worth investigating for Unity.