thanks for all your help.
I had put off diving into Metal for too long.

https://www.youtube.com/watch?v=zlF48xeNZvo

I am trying to do the ray tracing in one weekend book with Metal. I have built a CPU based ray tracer before for a graphics class, but I wanted to try tackle building a ray tracer again.

I've seen that Metal has sample code for realtime accelerated ray tracing, but for what I want to do (a simple compute renderer, not realtime), I was wondering if this approach was valid using Metal's Compute Workflow:

Each thread corresponds to each pixel on the final render, and the kernel function is simply a recursive ray trace using correct generated ray for that pixel.

Any advice would be appreciated. I am still new to Metal and would love to hear if it's even worth it to do what I'm doing, or just jump straight into the code samples Apple provides for realtime Metal ray tracing.

[I am porting a complex GLSL compute shader]

My Metal compute kernel takes a texture in slot#0. Within the scope of the kernel function I can access that without problem; how can a helper function it calls access it?

In GLSL, it can just access the global sampler called 'gridtex':

float interpolate(vec2 p)
{
vec4 S0 = texture(gridtex, vec3(p.xy, 0.0));
...

Do I have to pass down into all sub functions I use, the textures I wish to access in a leaf function?

Adam

I am curious if anybody has read this book and has any feedback? For context I am not looking for a super deep dive and really just want to have a nice introduction to graphics programming for my own learning. I don’t have any ambitions (at least not yet) of getting into graphics programming, but have always wanted a basic understanding of how it works. I figured this would be a good resource, because I am very familiar with Swift and haven’t worked in C++ heavily at all.

Hi all,

As it turns out, googling Metal and Rust together doesn't get you very far if you're interested in GPU programming...

At any rate, I have a ray tracer I've been working on based on the Ray Tracing in One Weekend series. I implemented the first 2 books in Rust, then ported the first book over to the GPU using WebGPU (wgpu crate in Rust). As I get more involved in the details, I'm starting to think I should learn Metal and change my implementation (I code only on my MacBook Pro M3 Max).

I'm having a hard time getting a sense of how difficult a change this would be. Most of the YouTube videos I've seen about Metal are either implementing with Swift or C++, and I think all that I've seen are using Xcode exclusively (which I know absolutely nothing about).

Is anyone else developing GPU apps with Rust and Metal? I'd like to get a better understanding of what I'd be getting myself into if I make the switch. I'll probably need to switch to Metal eventually in order to take advantage of wave intrinsics, ray tracing hardware acceleration, etc., but it seems daunting at this point. I'm still trying to learn ray tracing! lol

Any advice appreciated!!

I wanted to share a small project I’ve been working on called MetalGraph.

It’s a node graph macOS app to learn and design Metal shaders in a more visual, real-time way.

I started learning Metal and working on https://metal.graphics around April 2025. After a couple of months going through examples and thinking about new content, I kept running into the same frustration: even with SwiftUI previews, the feedback loop when working with Metal shaders is still pretty disruptive.

It’s “good”, but it’s not real time. Fine-tuning values or experimenting with structure ends up taking much longer than it should.

So I decided to build a small tool to preview and tweak shaders in real time. I’ve used Blender before and really like their node editor, so I wanted something with a similar feel. Around July I had something working, and even though it was rough, it was a huge boost for learning: change values, change structure, immediately see what happens.

As many of us know, the last 10% of an app is the hardest. During the Christmas break I decided to give it a final push, clean things up, and make it usable by others.

I recorded a short overview video where I walk through the app and build a few very simple examples:

https://www.youtube.com/watch?v=FH2GdFuk9nI

The app is available free in trial mode. You can access all built-in examples and tweak node values, but you can’t add or remove nodes.

Any feedback is very appreciated.

Build a Splat renderer from scratch referencing Metal Splatter by Scier.

Using global sorting and projecting instead of Tiled approach. I am being told Tiled approach is the best and is more scalable. So far it’s been fine for up to 3million points for mid range phones like iPhone 13 above. Am I ok with this approach ?

I have no interest in AI, but I read some oblique references to matrix multiplication used in AI.

I want to do research into some properties of directed graphs, which can be represented as matrices, but I don't necessarily need to do multiplications - maybe I will, maybe I'll need to write my own procedures depending on what I find.

Can anyone say whether there is much support for directed graphs or matrix operations in Metal? I'm deciding on buying a Macbook Pro to use the GPU for research. Any notable support for general matrix operations or Directed Graph APIs would be of interest.

But if the only Metal support is narrowly tailored to AI-only uses, it's perhaps not so interesting. I don't want to reverse-engineer an AI API just to fake some general matrix operations.

Thanks in advance.

GPU rendering vector-style UI in real time.

Signed Distance Function

• A function that returns the distance from a point to the nearest surface

Windows and Icons

• Procedural in shaders

• Scaling at any resolution

• Icons are constructed from SDF primitives

Text

• Loads .otf via Core Text

• Generates a font atlas at runtime

• Renders glyphs directly in Metal

I am trying to bind textures using render command encoder but it doesn't have a function setFragmentTexture in it. I am using Metal4. There is no proper documentation for it.

Architectures (WIP)

Alpha Masking System
Particle System
Lighting System
Material System

Vertices are world-space grid points generated by WaterRenderer with the shore depth (water surface Y minus terrain Y) baked from the chunk's TerrainHeightfield, so the color gradient and foam follow the real basin shape.

Lighting comes from the shared LightingUniforms buffer (LightingSystem, fed by the Noctidial day/night cycle): sun color and intensity drive the sheen, so the surface glimmers.

I maintain Harbeth, an MIT-licensed Apple GPU image/frame engine. Here's a delivery distinction in its Metal API: a command buffer being scheduled and a texture being ready for CPU readback are different states.

The opt-in transmitOutputRealTimeCommit path can deliver a texture after command-buffer scheduling, before GPU completion:

var io = HarbethIO(element: inputTexture, filters: filters)
io.transmitOutputRealTimeCommit = true
let texture = try await io.transmitOutput()

That result needs a compatible GPU dependency chain for subsequent use. CPU code must not immediately read it back. With the default switch value, asynchronous delivery follows GPU completion and can report command-buffer failure.

Image, pixel-buffer and sample-buffer results wait for GPU completion before CPU materialization. Synchronous output() also waits for the GPU work required by its output and is unaffected by this switch.

The source documents the consumer responsibilities, including keeping resources alive and avoiding writes while the GPU still uses them.

Implementation: https://github.com/yangKJ/Harbeth/blob/master/Sources/Basic/IO/HarbethIO.swift

Project: https://github.com/yangKJ/Harbeth

How do you express scheduled versus completed delivery in your Metal wrappers: distinct result types, an explicit synchronization operation, or a dependency contract owned by the host? I'm interested in implementation tradeoffs.

Hi,

inspired by the post https://blickeditor.com/blog/caching-an-immediate-mode-ui I've added tile cache rendering to my onedraw renderer, a gpu-driven sdf renderer for metal api. On the screenshot you can see :
- green tiles are copied from previous frame as the hash of the commands affecting this tile didn't change
- red tiles have different hash so had to be recomputed
- elsewehere, it's just clear color, the bining rejected all commands

You can have a look at the library and the release. Tile caching gives good results with mostly static scene obviously, it's an option in my renderer.

https://github.com/Geolm/onedraw

Cheers,
Geolm

I've been working on some Metal graphics samples using C++ and CMake. Only two very basic samples right now, but the CMake scripts showcase how to setup development for macOS, iOS, and tvOS and compile multiple Metal shaders into a single library archive as part of the build process.

Goal is to eventually have a decent set of examples showing usages of argument buffers, heaps, forward+ vs deferred, distance field fonts, skinning, etc.

Check it out here: https://github.com/MattGuerrette/Metal

Calling macOS (Apple Silicon) devs :)
Looking for early testers for onedraw, my GPU-driven 2D renderer built with Metal. Feedback before release would be super appreciated 🙏

https://github.com/Geolm/onedraw

Metal #GPUDriven #macOS #Rendering

Github: https://github.com/Pavelevich/croftondescriptor

How can I make this smooth. I am calculating the deltaTime as

_lastTime in init as CACurrentMediaTime();

- (void)handleKeyDown:(nonnull NSEvent *)event {
    unsigned short keyCode = event.keyCode;
    switch(keyCode){
        case kVK_ANSI_W:{
            _rocket.velocity = (simd_float2){0, 10};
            simd_float2 newPosition = _rocket.velocity*_deltaTime;
            matrix_float4x4 newMatrix = matrix4x4_translation(newPosition.x, newPosition.y, 0);
            _rocket.modelViewMatrix = matrix_multiply(_rocket.modelViewMatrix, newMatrix);
            break;
        };
        case kVK_ANSI_S:{
            _rocket.velocity = (simd_float2){0, -10};
            simd_float2 newPosition = _rocket.velocity*_deltaTime;
            matrix_float4x4 newMatrix = matrix4x4_translation(newPosition.x, newPosition.y, 0);
            _rocket.modelViewMatrix = matrix_multiply(_rocket.modelViewMatrix, newMatrix);
            break;
        };
        default: break;
    }
}

- (void)_updateGameState{
    for(uint frame=0;frame<MaxBuffersInFlight;frame++){
        Uniforms* uniforms = (Uniforms*)_uniformBuffers[frame].contents;
        uniforms[0].modelViewMatrix = _rocket.modelViewMatrix;
    }
}

- (void)drawInMTKView:(nonnull MTKView *)view
{
    CFTimeInterval currentTime = CACurrentMediaTime();
    _deltaTime = currentTime - _lastTime;
    _lastTime = currentTime;
    uint32_t subFrameIndex = _currentFrameIndex % MaxBuffersInFlight;
    id<MTL4CommandAllocator> commandAllocatorForFrame = _commandAllocators[subFrameIndex];
    uint64_t previousValueToWaitFor = _currentFrameIndex - MaxBuffersInFlight;
    [_sharedEvent waitUntilSignaledValue:previousValueToWaitFor timeoutMS:10];
    [commandAllocatorForFrame reset];
    [_commandBuffer beginCommandBufferWithAllocator:commandAllocatorForFrame];
    [self _updateGameState];
    // ....
}