0

I am in the process of trying to write a Monte Carlo Path tracer using Metal. I have the entire pipeline working (almost) correctly. I have some weird banding issues, but that seems like it has more to do with my path tracing logic than with Metal.

For people who may not have experience with path tracer, what it does is generates rays from the camera, bounces it around the scene in random directions for a given depth (in my case, 8), and at every intersection/bounce it shades the ray with that material's color. The end goal is for it to "converge" to a very nice and clean image by averaging out many iterations over and over again. In my code, my metal compute pipeline is run over and over again, with the pipeline representing an iteration.

The way I've structured my compute pipeline is using the following stages:

  • Generate Rays

  • Looping 8 times (i.e. bounce the ray around 8 times) :

    1 - Compute Ray Intersections and Bounce it off that intersection (recalculate direction) 2 - "Shade" the ray's color based on that intersection

  • Get the average of all iterations by getting the current texture buffer's color, multiplying it by iteration and then add the ray's color to it, then divide by iteration+1. Then store that new combined_color in the same exact buffer location.

So on an even higher level what my entire Renderer does is:

1 - Do a bunch of ray calculations in a compute shader 2 - Update Buffer (which is the MTKView's drawable)

The problem is that for some reason, what happens is that my texture cycles between 3 different levels of color accumulation and keeps glitching between different colors, almost as if there are three different programs trying to write to the same buffer. This can't be due to race conditions because we're reading and writing from the same buffer location right? How can this be happening?

Here is my system trace of the first few iterations:

System Trace Overview

As you can see, for the first few iterations, it doesn't render anything for some reason, and they're super fast. I have no clue why that is. Then later, the iterations are very slow. Here is a close-up of that first part: System Trace Close-up

I've tried outputting just a single iteration's color every time, and it seems perfectly fine. My picture doesn't converge to a clean image (which is what happens after multiple iterations are averaged)

I've tried using semaphores to synchronize things, but all I end up with is a stalled program because I keep waiting for the command buffer and for some reason it is never ready. I think I may just not be getting semaphores. I've tried looking things up and I seem to be doing it right.

Help.. I've been working on this bug for two days. I can't fix it. I've tried everything. I just do not know enough to even begin to discern the problem. Here is a link to the project. The system trace file can be found under System Traces/NaiveIntegrator.trace. I hate to just paste in my code, and I understand this is not recommended at SO, but the problem is I just have no idea where the bug could be. I promise that as soon as the problem is fixed I'll paste the relevant code snippets here.

If you run the code you will see a simple cornell box with a yellow sphere in the middle. If you leave the code running for a while you'll see that the third image in the cycle eventually converges to a decent image (ignoring the banding effect on the floor that is probably irrelevant). But the problem is that the image keeps flickering between 3 different images.

Vertexwahn
  • 7,709
  • 6
  • 64
  • 90
JoeVictor
  • 1,806
  • 1
  • 17
  • 38
  • From the [description of Function Texture Read-Writes](https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/WhatsNewiniOS10tvOS10andOSX1012/WhatsNewiniOS10tvOS10andOSX1012.html#//apple_ref/doc/uid/TP40014221-CH14-DontLinkElementID_66) in the Metal Programming Guide, just above Listing 11-6: "**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." Use a single texture parameter with `access::read_write`. – Ken Thomases Nov 24 '17 at 04:59
  • Also, is `ray.idx_bounces.xy` unique per invocation/thread of `kern_FinalGather()`? That is, are you sure that only one thread at a time can be reading or writing a given position, that there are no races? – Ken Thomases Nov 24 '17 at 05:00
  • So I tried using read_write. It's the first thing I tried. If you do that, you will see that the image slowly converges to black. That is because it is not reading correctly from the texture. I have no clue why – JoeVictor Nov 24 '17 at 05:02
  • `ray.idx_bounces.xy` is just the (x,y) coordinates of a ray. So it is unique per thread as each ray is uniquely generted from a pixel. – JoeVictor Nov 24 '17 at 05:03
  • I have a slight hacky fix that works! Basically if you accumulate the rays in a separate buffer, and then write them out to the drawable's texture directly, it converges correctly. (Using the same indexing). I don't like this solution though as this means I don't get to learn what was wrong in my previous implementation. Code is pushed if you want to take a look. – JoeVictor Nov 24 '17 at 05:06
  • (Deleted my question about `framebufferOnly` after finding that, myself.) You are using the drawable's texture, whose format is `.bgra8Unorm`, but texture read-writes are only supported for specific formats, which don't include that. Does `access::read_write` work with a texture of a supported format? – Ken Thomases Nov 24 '17 at 05:11
  • Sorry, I hate and refuse to use the chat feature. I know SO encourages us to switch to it, but, no. :) – Ken Thomases Nov 24 '17 at 05:16
  • OK, fair enough. May you please clarify what you mean by "texture of a supported format"? – JoeVictor Nov 24 '17 at 05:20
  • At the link I posted above to the Metal Programming Guide, if you scroll down past Listing 11-8, there's a discussion of the pixel formats which are supported for texture read-write. You would need to use a texture of one of those pixel formats if you want to keep using the texture approach. (And, hopefully, if you do, you'll be able to use `access::read_write` instead of violating the rule I cited above.) – Ken Thomases Nov 24 '17 at 07:02
  • Oh yes, it seems that the format I'm using, `RGBA8Unorm` is only supported for Tier 2 machines, which mine is not. I guess that fixes things. Thanks! – JoeVictor Nov 24 '17 at 14:28
  • You're not using `RGBA8Unorm` as far as I saw, you're using `BGRA8Unorm`. That's not in either tier. – Ken Thomases Nov 24 '17 at 21:37
  • Hmm.. I'm gonna have to look further into this.... Switching to rgba8unorm breaks my code. – JoeVictor Nov 24 '17 at 22:40

0 Answers0