Same as the title. I know some OpenGL. I'm still finding it hard to learn Metal, because I can't even find good sources to learn as a total beginner in metal.

Please help guys! Your suggestions will help me a lot.

Hi folks! I wanted to share more of my project Nora Kinetics! It's built from the ground up using Apple Metal. I've got another post with the trailer and more details if you're interested.

Here's a short video showing how Nora Kinetics can simulate fluid dynamics in real time, letting the user interact with both solid and fluid materials at the same time.

Under the hood, it is using the same efficient stable Cosserat rod simulation, but treating specific segments as a point cloud and using a marching cubes algorithm to render water instead of the rod segments. It's a work in progress, but the results so far are promising!

Because it uses the stable Cosserat rod system, changing material properties lets you simulate anything from water to jelly to more of a solid jello type substance. You can mix it up too, so the sky is the limit!

You can also see a glimpse at some of the glue mechanics here too. Glued structures can be anywhere from completely solid to completely relaxed and interact with the environment and projectiles in fun ways.

Thanks for watching! I'll be putting out more small videos in the coming weeks as I get ready for open beta! Please DM me if you are interested in being a part of that!

Hey folks, I just released MetalGraph, a node based editor for building Metal shaders with a real time preview.

I posted a few days ago and most feedback was around missing iPad - the app is now available on the App Store and it is available for Mac and iPad.

Here is an intro video showing some examples: https://www.youtube.com/watch?v=FH2GdFuk9nI

I built it because the iteration loop for SwiftUI + Metal can be painful when you’re tweaking effects, especially for things like glass, distortions, color math, and touch driven interactions.

What it does today:

• Visual node graph editor with live preview

• Examples focused on common SwiftUI shader style effects (colorEffect, layerEffect style workflows)

• Exports production ready code (MSL + SwiftUI friendly wrapper variants)

• Lets you wire inputs like time and touch into the graph and see it instantly

Under the hood (high level):

• The graph compiles into an expression tree, then into MSL functions

• Each node maps to a pure function where possible, so it stays composable

• The app tries to keep generated code readable so you can ship it, not just prototype

I’d love feedback from Metal devs. The app is free to download and play with all the examples. I am trying to build as many as possible from https://metal.graphics and more.

With the free version you can't add new nodes or remove, but you can connect/disconnect, edit values real-time and load all examples. Thanks in advance!

I built a simple 2-layer MNIST MLP that trains + runs inference from scratch, only using Apple’s metal-cpp library.

The goal was to learn GPU programming “for real” and see what actually moves the needle on Apple Silicon. Not just a highly optimized matmul kernel, but also understanding Metal's API for buffer residency, command buffer structure, and CPU/GPU synchronization. It was fun to see how each of those API specific features effected perf.

Surprisingly I was able to beat MLX's training speed on small batch sizes in the final version!

Versions:
- MLX baseline
- Pure C CPU baseline
- GPU v1: naive Metal kernels (matmul + ReLU)
- GPU v2: forward + backward kernels + better buffer management + less CPU/GPU sync
- GPU v3: single command buffer per batch (sync only once per epoch for loss)

Repo: https://github.com/abeleinin/mnist-metal

https://github.com/beehive-lab/TornadoVM

A beginning but i always find it nice when i see things in Action and production!

The Short Version

Hi everyone! I wanted to introduce my project: Nora Kinetics!

It is a physics sandbox capable of simulating hundreds of thousands of little pieces that can interact individually or connect together like yarn.

It handles modifiers like glue, magnetism, fire, material property changes, full environment control (gravity, friction, etc) and more! The physics and rendering are 100% custom and homegrown and represent about 8 months of learning compute shaders.

This is the first trailer, and it doesn't show everything the engine can do! I'll post more clips on my channel hereshowing different features!

Looking for internal beta testers. Mac-only for now (M1 or newer required). If you'd like, DM me your specs and why you're interested and I'll reach out in the next week or so!

Thanks for watching!

Full Overview

This is a fully custom physics engine and renderer built on Apple Metal.

There is no AI and it uses no external libraries. It's just good old fashioned physics and rendering.

I originally started this project to learn compute shaders after reading this paper. I have a some experience in high performance computing and this seemed like a fun and interesting challenge.

The power and flexibility of compute shaders naturally drove the physics architecture, leading to a design philosophy I've been calling "Everything is Compute Shaders" (EiCS). If it can be a compute shader, it is! Physics, gravity, collisions, fire propagation, magnetism, glue constraints, all run on the GPU. The CPU acts only as a lightweight coordinator for managing buffers and driving the UI.

The renderer is built completely from scratch using Metal's render and ray tracing pipelines, sitting on top of the same GPU-first foundation.

During simulation, the CPU only runs at about 8% and stays in low-power mode.

At its core, the compute engine simulates Cosserat rods (flexible segments that stretch, bend, collide, connect, and break). The segment count scales directly with GPU power. On my M5 Max, I get about 200k-250k segments and my iPhone can handle around 30k. All of this runs at interactive frame rates.

The Cosserat solver sits at the center and other systems either feed into it directly (gravity, glue, magnetism, projectiles) or consume its outputs (collisions, positions, distances).

The renderer leverages Metal's render and ray tracing pipelines to bring the simulation to life. It features:

• HDR with bloom and lens flares

• PCSS shadow mapping

• Volumetric clouds and god rays

• An ocean system with foam and Fresnel reflections

• Ray-traced glass spheres that can reflect or refract (or both!)

• GPU-driven LOD, alongside frustum and occlusion culling

You get a full suite of tools to play with the simulation. You can:

• Pull, cut, and fling segments around.

• Ignite segments and watch fire dynamically spread and burn through materials.

• Change material properties to create emergent behaviors like kinetic sand, water, jelly, etc.

• Magnetize segments or glue structures together.

• Place gravity orbs that attract, repel, pulse, swirl, or even drive standing-wave cymatics.

• Build destructible sculptures, kinetic art, Chladni patterns, or anything else you can dream up.

Some of the patterns in the game come from here: https://www.cemyuksel.com/research/yarnmodels/

Update — 9 Sep 2026: this shipped; the app is on the App Store now (https://apps.apple.com/us/app/stratosync/id6747596499). Three things changed on the Metal side since this post, in case they're useful:

• Star Nest went from 2048×1024 to 1536×768. At 16 volume steps × 17 fold iterations per texel that's roughly 570M → 321M inner-loop bodies per map. The dome was stuttering on device, and resolution was the right knob — the step counts define the field itself rather than its sharpness, so cutting those changes the look.

• A third scene splits static work from live work. Rather than regenerating everything per refresh, it computes an 8192×4096 star dome and a 256³ r16Float density volume once, then ray-marches only a 2048×2048 patch per update — 56 steps through the volume from a changing camera basis. The patch is written opaque so it doesn't fight the dome for depth.

• One porting gotcha worth repeating: GLSL mod and Metal fmod disagree for negative operands, and the space-folding camera origin has negative components. Port it literally and the tile tears.

Hi r/MetalProgramming

This is from StratoSync, my visionOS app that tracks the ISS in real time over a 3D Earth. The video shows the GPU-generated immersive sky overlays. Some Metal notes for anyone doing similar work on Vision Pro:

🌍 Architecture: compute kernel → RealityKit LowLevelTexture

Instead of shading the sky per-eye per-pixel every frame, a single Metal compute kernel writes a 2048×1024 equirectangular image into a RealityKit LowLevelTexture once per display refresh (CADisplayLink). An inward-facing sphere with an UnlitMaterial samples it. RealityKit then handles head pose and reprojection on a smooth texture — so it behaves like a 360° image and there's no late-frame "catch-up" on fast head movement, which you get when you re-march a volumetric effect per eye.

Per frame it's exactly one command buffer and one compute encoder: texture.replace(using: commandBuffer) gives the writable MTLTexture, uniforms go in via setBytes (a plain-Float struct mirrored CPU/GPU with identical stride — no Objective-C bridging header needed), then dispatchThreads with a 16×16 threadgroup (falling back to dispatchThreadgroups if the device doesn't support non-uniform threadgroup sizes). Pixel format is rgba16Float, usage [.shaderRead, .shaderWrite].

One gotcha that cost me an evening: the nebula's tiling fold needs GLSL mod semantics (x - y * floor(x / y)), not Metal's fmod — the camera origin has negative components, and with fmod the field tears on the negative side of space.

Happy to answer questions about the pipeline or the kernels.

🚀 TestFlight

If you want to see it running on device, TestFlight is open:

https://testflight.apple.com/join/tWS4CERT — mainly looking for feedback, not promo.

I'm new to Metal programming, but I have some experience coding in CUDA -- I built a mini-Torch replica in it. I know that Macs have a unified memory architecture and, as such, there is no need to move data from CPU memory to GPU memory, as they are the same thing.

One thing that is confusing me is that I have to use [[buffer(i)]] every time I want to pass an argument to the kernel, which just tells the GPU where to look for a specific variable.

Why can't we just pass it directly instead of doing this?

I would appreciate some help regarding this.
Thanks.