RasterCommandBuffer.ClearRenderTarget color not working on macOS / Metal

Unity Engine
, , , , ,
1

Hi!

I have a custom renderer feature which, when executing a pass, has a call like this:

private static void ExecutePass(LayersToTexturesPassData passData, RasterGraphContext context)
{
    RasterCommandBuffer cmd = context.cmd;
    cmd.ClearRenderTarget(RTClearFlags.ColorDepth, passData.BackgroundColor, 0, 0);
    // ...etc
}

As an example, I have passData.BackgroundColor set to (1,0,0,1) (Red).

On Windows (using Direct3D API), I can check the frame debugger to see that the clear color is working correctly:

image
image646×636 10.8 KB

(not sure why Clear Color at the bottom is always {1,0,1,1} no matter what I set passData.BackgroundColor to, but it’s clearing to red properly anyway.)

Here’s the exact same pass on macOS (Apple Silicon which can only use Metal API):

image
image647×638 10.5 KB

On Mac, it’s clearing to black (or probably actually Clear, IE {0,0,0,0}) instead of red.

So… what gives? Why does the color passed into RasterCommandBuffer.ClearRenderTarget go black/zero out on macOS & Metal?

This is Unity 6.0, URP 17.0.4. Thank you! :folded_hands:

2

Hi! This seems to me like a bug in Unity on our Metal driver. Would it be possible to create a bug report? Thank you!

3

Sure thing, I made a small sample project demonstrating the issue and sent it in a bug report yesterday via the editor.

I’ve attached that project here as well in case anyone can take a look at it. Unity 6000.0.48f1, “OPEN THIS SCENE” is the name of the scene to test things - clear colors work correctly on PC, don’t work correctly on Apple Silicon Mac.
ClearColorBugReportProject.zip (338.4 KB)

I never got any email confirmation from my bug report, though. Should I try to submit it again in a different way (e.g. via Unity Hub), or just leave it?

In the meantime as a workaround I’m going to try using the RasterCommandBuffer to draw a fullscreen quad of the desired color to the render target, where the call to ClearRenderTarget would normally happen, and see if that works. Not sure how to do this with access only to RasterCommandBuffer however. I can’t just make calls to something like the Blitter class because I have other commands recorded to the buffer which need to work in the correct order.
(EDIT: I figured this step out, and it appears to do what I need it to do, drawing the color fullscreen as a workaround. Still interested in the progress on the bug however, since it would be more optimal to get clears working instead of adding additional mesh drawing.)

4

Hi! Thank you for sending the reproduction project! This issue has not been fixed in 6.0 yet. But it has been fixed in 6.1 and 6.2.

I haven’t been able to find your bug report. I think you can try to submit it again (maybe using Unity Hub like you mentioned). It will help us prioritize backporting this fix and track progress :slight_smile:

5

I submitted it again via Unity Hub and actually got a confirmation email this time, so it appears to have worked. The bug report’s summary is RasterCommandBuffer.ClearRenderTarget breaks on Metal.

That’s cool that it’s already been fixed in 6.1 and 6.2, I’ll give those a try as well and report back if there’s any further issues. And of course I’ll stay tuned to 6.0 updates that fix it. Thanks for your help! :folded_hands:

6

Hi! Thank you for making the bug report. This should be fixed in 6000.0.64f1. Please let us know if you have any other problems :smiley:

7

Much appreciated! Cool to see that this will appear in a future version. Sadly, a new issue did indeed arrive, so I’m taking you up on the offer to help :sweat_smile:

Since I made the original post, we moved the project from 6000.0.48f1 to 6000.0.62f1 for console validation reasons (meaning the upcoming 64f1 is probably non-viable, and we can’t go to 6.1+ versions for internal reasons). I had a Mac/Metal workaround which works on 48f1 (replacing incorrect clear colors with a fullscreen mesh draw of the correct color), so I assumed it should be fine for 62f1 as well. However, whether in editor or build, visuals are now even more broken on Mac (everything still looks correct on PC). Most of the effects enabled by this custom renderer feature simply don’t work anymore, even those that don’t rely on specific clear colors.

What’s odd, though, is that if I enable the frame debugger, the frame on which it pauses looks correct. Everything appears exactly as it should, just like on PC. Stepping through the draw calls, everything is in its expected place. Playing the game, it’s like values in certain shaders get “stuck” and don’t update, and things look wrong. But every time I take a frame debugger snapshot, while the game view is paused the visuals look perfect and the analysis shows the correct draw operations in the correct order.

This leads me to believe that there is some change in the order of rendering operations or the usage of internal resources from 48f1 to 62f1 on Mac/Metal specifically, perhaps causing some kind of race condition in normal play, but I cannot yet figure out what the problem is or how to fix it since PC works perfectly and the frame debugger shows everything working perfectly on both PC & Mac. Any ideas??? :thinking:

8

I would recommend 6000.0.64 for Metal as there were some critical bug fixes in this version that are present in 6000.0.62. These are the release notes: Unity 6000.0.64f1.

I guess you are using the Universal Render Pipeline? I wonder if it has something to do with the URP render graph.. Or are you using the URP compatibility mode?

Otherwise I don’t have any other ideas than submitting a new bug report :sweat_smile:

Thank you!

9

We might not be able to use 6000.0.64 unless it gets validated for all the consoles we’re porting to, and since it just released it’s possible that doesn’t happen in time for us, which is why I’ve been trying to get things working on 6000.0.62 (previous version 6000.0.48 was also no good for console validation).\

EDIT: Tested on 6000.0.64. The Mac bug I reported is indeed fixed! However, things still don’t look correct, due to the same strange new issue that 6000.0.62 introduced (once again, everything looks perfect in the frame debugger snapshot, but not elsewhere).

Yes we’re on URP (2D), and compatibility mode is disabled. The renderer feature goes through URP Render Graph. With my Mac workaround, everything worked on 6000.0.48, and everything appears correct in the frame debugger snapshot in 6000.0.62. I’ll continue to compare analysis on the PC to the Mac and see if I can discover anything else. Thanks!

I’m not even sure what the bug is yet :sweat_smile: and reproducing it requires a whole lot more of the real project, since some isolated attempts in new test projects haven’t repro’d the issue. I guess I can report the bug as things appearing different between frame debugger and normal play and that will help locate the issue? I’ll have to see what we can do. Thanks!

10

I figured something out: using overlay cameras seems to break something in the syncing of draws, but perhaps only for renderer features that write to shader global textures. Disabling the overlay cameras and keeping the base camera allows all of the effects created by the renderer feature to appear correctly on the Mac. Taking a snapshot with the frame debugger seems to sync everything correctly as well. So the overlay cameras are probably doing something they’re not supposed to be doing, and it seems to affect the vfx writing & reading shader global textures more.

Going to put together another isolated bug report, as this behaviour is inconsistent between Mac and Mac frame debugger/PC. I hope this is the last one :sweat_smile::sweat_smile:

Please let me know if you’re aware of anything changing from 6000.0.48f1 to more recent versions which would affect how overlay cameras interact with the rendering of the base camera and ordering/syncing in render graph on Metal, particularly around writing to shader global textures. :folded_hands:

11

Hi @NPTP!

Thank you for reporting the bug. Do you have a link or ID to the bug you reported so that I can check it? Something like UUM-

12

Got caught up with other work, the holidays, and had trouble isolating the bug from an otherwise large project, but just sent it in now!

IN-130136 is the bug report ID. I attached an isolated project again which shows a clear discrepancy on PC vs. Mac, and which exists in both editor and built player, and an issue which did not exist back in 6000.0.48f1 when I originally implemented the custom renderer feature.

Let me know any updates and thanks for your continued support throughout all this :folded_hands:

13

Update: bug is confirmed, internal ID is UUM-131886

14

^ Looks like it’s under consideration for 6000.5 :smiling_face_with_tear:

The fix will arrive in a Unity version that we can’t use for the upcoming (commercial) release of this game where this bug was coming up, any way that could get it into a 6000.0 version considering it’s a regression from 6000.0.50f1? :sweat_smile::sweat_smile:

15

A post for posterity here: this is a very niche issue, but in case anyone comes across this thread in future, here was Unity’s suggestion on the final bug report:

Thank you for reporting a bug to Unity.

As mentioned by the developer, the rendergraph pipeline requires specific management of global textures and its state (read/write). For the RecordRenderGraph in LayersToTexturesRenderPass.cs, you can use the following code to fix the issue.

builder.UseAllGlobalTextures(true);

Or if you are expecting to read from a specific texture, use

builder.UseTexture(myTexture);

Using builder.UseAllGlobalTextures(true); did sort out the issue on Metal with overlay cameras! It doesn’t fully explain the discrepancy between PC and Mac which the Unity team also encountered, but perhaps this will be more consistent.

In the end, we managed to get things working satisfactorily on PC and Mac platforms. Will report back if console platforms present new issues (we should find out soon). In the meantime it looks good.

16

OK WELL I’M BACK AGAIN!
Looks like problems have resurfaced. The constant changes to URP under the hood keep breaking the render features, and I guess they’re too niche for anyone to notice :sweat_smile: Even Unity’s own samples don’t work 100% now.

I started a new thread for some new troubles with Unity 6.4 and URP 17.4.0. You can find it here: RendererList-based URP render feature breaks in 2D in 6.4 (but works fine in 6.0!)