But at this stage, when “Build and Run” I have this bug
**2020-05-23 18:17:03.344388+0200 Raytracing[18963:2774266] Metal GPU Frame Capture Enabled**
**2020-05-23 18:17:03.344670+0200 Raytracing[18963:2774266] Metal API Validation Enabled**
**validateComputeFunctionArguments:834: failed assertion `Compute Function(accumulatedKernel): Shader uses texture(t[1]) as read-write, but hardware does not support read-write texture of this pixel format.'**
**(lldb)**
I’m having this problem (created duplicate thread, pasting it in here, I’ll try the posted work-around tonight but note that work-around is advised against by Apple, I believe):
I’m hitting a failed assertion on the run before section 1.5 (“Create the acceleration structurre”) on a 2018 MacBook Pro, and the problem persists through to the supplied (i.e. not coded by me) final project. The build succeeds but then I immediately get:
“validateComputeFunctionArguments:834: failed assertion `Compute Function(accumulateKernel): Shader uses texture(t[1]) as read-write, but hardware does not support read-write texture of this pixel format.'”
(In the final project it moves to the shadowKernel:)
“validateComputeFunctionArguments:834: failed assertion `Compute Function(shadowKernel): Shader uses texture(renderTarget[0]) as read-write, but hardware does not support read-write texture of this pixel format.'”
It’s happening with both the Xcode beta and release versions. I found on apple developer forums someone may have got it working by passing the texture twice, with read and write access, but this is apparently not a good idea. I’ll try it anyway to see if it works.
Hi there - I just ran the supplied final project on my 2019 MacBook Pro in both Xcode 11 and Xcode 12 beta 3 on Catalina 10.15.6, and it seems to run fine on mine. Is your configuration any different?
If you’re using Xcode 12, does it run in Xcode 11?
What GPU do you have? You can find out by print(device.description).
I found it doesn’t work when I switch to the integrated Intel GPU. I don’t think there’s much I can suggest, I’m afraid.
Oops, I’m on beta 2, I’ll start downloading 3 now. The above fix has got me past the first mid-section run; I’m working on the others now also. Thanks Caroline!
<CaptureMTLDevice: 0x600003310d20> → <MTLDebugDevice: 0x1022385b0> → <MTLIGAccelDevice: 0x102600000>
name = Intel(R) Iris™ Plus Graphics 655
As you say … if (device = Intel) { return sadTrombone.aif }
Haven’t tried iOS yet, but I’ve got to the build & run right before section 2 (Shadow Rays), and it’s still running with the above fix (using the texture twice with .read and .write permissions). It looks like I’ll need to implement the fix again for the Shadow Kernel, judging by what the final version is failing on, but I’ll let you know how it goes.
(When I was saying “this is apparently not a good idea”, I was referring to:
“Note: It is invalid to declare two separate texture arguments (one read, one write) in a function signature and then set the same texture for both.”
You may have issues especially regarding synchronization with read/write between different kernel threads. I’m surprised that the Metal API validation isn’t complaining.
Unless you can make sure that all the hardware / OS you want to support have read-write texture support, you need to provide an implementation that doesn’t need this read-write support.
Confirmed it works on my phone without fixes, and on my MacBook in the final state with the fix implemented twice (one for each kernel function that requires read and write to the same texture). Thanks Caroline!