I don't understand, if you are doing ray-tracing then there are BLAS and TLAS BVH structures that wrap rigid models, and allow the ray to quickly hit triangles and then resolve attributes. The only limitation there is that all positions must be in a single VB.

Apple has always had VK_EXT_shader_object, it's Vulkan that locked everything down into rigid PSO. I would assume like ray-tracing, that's the ability to splice in bits of code.

For lack of anything better, I'll assume detecting ProMotion on iOS is UIScreen.maximumRefreshRate > 80. But I'd like to know I have ProMotion even when it's throttled to 60Hz. Also seems that there is no detect for the "fullscreen" hack of running iOS app on macOS. The app starts up at the full res of the display, and stays that resolution even when you drop out of fullscreen mode (fn+F). The windowed mode can't really be resized, so this must be the tradeoff for this mode, and it beats adopting MacCatalyst. So we're rendering a lot more pixels than needed in windowed mode, and can't tell fullscreen vs. not by comparing the UIScreen rect and UIView size. Maybe I can test the UIWindow size instead, since that seems smaller than the view res in this case. I'll probably have to submit this as a precious ticket to get any response to these issues.

Also have an iOS app using running atop a Macbook Pro M2 with ProMotion. So here again, I assume I need to detect fullscreen setting and whether ProMotion is present but from the iOS side. But IOS doesn't seem to have these APIs and there's nothing in the docs or WWDC talk about detection. Also frustrating that sysctl(HW, HW_MODEL) works on macOS running iOS (but not for iOS), but sysctl(HW, HW_MACHINE) returns the wrong value. HW_MACHINE returns that the M2 is an iPad8,6. Apple really needs to release sample code to better support this, and any sample for ProMotion on both platforms included detection code.

I'd like to know where the Metal sample app is that they mention in the WWDC 21 presentation. But check that out since it has a lot of simple things to get all this working. Also trying to search for "ProMotion" and getting tons of hits for "promotion" stinks. Can we just call this VRR like everyone else instead? Also CVDisplayLink has been forced to 60Hz when running under Rosetta 2 since Monterrey due to an Apple bug. https://developer.apple.com/videos/play/wwdc2021/10147/

This error in CVDisplayLink has been occurring since the release of Moneterrey beta over 1.5 years ago. The messages only occur when running x64 apps under Rosetta 2. And the early logs show that the display link is forced to 60Hz, which basically kills ProMotion adaptive sync on M1/M2 at 120Hz. Then it streams a ton of repeated NSLog messages at 60Hz to the console which further slow down our app. The suggestions to set OS_ACTIVITY_MODE disabled to suppress with the repeated logs works, but then also suppresses all NSLog from ours and any Apple libraries. I don't understand how this hasn't been fixed, since I'm now on macOS 13.3.1, and was on macOS 12.0 when this started happening.

OpenGL is dead, and Vulkan is overly complex to use. MoltenVK is good enough, and with VK_EXT_shader_object support, it should be able to make Vulkan emulate Metal/DX11. Vulkan is moving back to shaders and dynamic state from the locked-down PSOs that it started with. Even AMD's consoles aren't that locked down in their graphics APIs. Metal and metal-cpp aren't that hard to grasp, and tie direclty in with the hardware used on the desktop and mobile side.

You can also just create your own depth texture, you don't have to have the MTKView create one. But then setup your own renderpass to the framebuffer + depth you create, and you then have to keep that depth in sync.

My understanding is that MTLFence don't work across command buffers. That's so you don't get a race on a resource that is changed within a command buffer. So when you go to untracked resources, Metal stops injecting fences for you. You said you had two command buffers. MTLEvent for cross command buffer, and MTLSharedEvent for synchronization across command queues, but few people do that.

Since there are never any responds to posts to the forums. I'll just post the solution for now. This is less than ideal, since it creates a whole new matrix, when a cast should be fine and is in HLSL. Neither cast not construction works directly from a float4x4/half4x4, but this does. inline float3x3 tofloat3x3(float4x4 m) { return float3x3(m[0].xyz, m[1].xyz, m[2].xyz); } inline half3x3 tohalf3x3(half4x4 m) { return half3x3(m[0].xyz, m[1].xyz, m[2].xyz); }

MTLEvent is what you need. You have to prevent concurrent execution of commands when you have two separate command buffers. Even with one, the compute and render passes can overlap, so then fences/barriers are needed.

For uint64_t, the specification states "Since Metal 2.2". So you have to compile to that, and make sure your iOS/macOS target is correct.

GL and ES are all dead everywhere. Vulkan has supplanted them on Android/Windows/Linux. ES 3.2 and GL 4.6 is probably the last version. On macOS, you only have GL4.1 which lacks compute, glClipControl, error callbacks, BC6/7 support, and much more. You can still use GL on M1, but it is emulated atop Metal. So it's time for devs to move on.

You have to tile it yourself, or use one of Apple's tiling classes. UIKit has some of these. But handling blurs across tiles isn't fun. The M1/iOS hw is TBDR, so it's further tiling up the image into 32x32 tiles, and only drawing elements within. So that is how you reduce bandwidth. Otherwise, you need a dirty rect system. The sparse texture is mostly for reading textures. Like in game, having a megatexture, and only pulling int tiles that were needed to display. It's also only on A13 and higher.

There are multiple CUs processing both Vertex and Fragment work. So that's what you are seeing the capture. You really shouldn't have one draw per command buffer. You should have one (or a small number of command buffers) that are enqued in the order you want the queue to process them in, and then use a series of render passes on the command buffer to submit draws that pertain to a particular set of render targets. The encoders of the render passes will run in sequence within a command buffer, but command buffers are allowed to execute out of order if there are no dependencies. CommandBuffers aren't cheap.