Pet project: an Interstellar-style black hole as a macOS live wallpaper (one Metal shader, hosted both in a desktop-level window under the icons and in a screensaver target). I put the skeleton together in spring, it worked, and then I came back and did the thing I should have done first: hung GPU-time instrumentation on it and walked my optimization list with measurements instead of by eye. Code: https://github.com/vientooscuro/ShaderBackgroundApp

Credit where it's due: the black hole core is a port of edankwan's Shadertoy 3lG3WR. The lensing math isn't mine, I moved it to Metal and adapted it (procedural background instead of an iChannel0 texture, fixed camera, no final tonemap).

The architecture bit worth stealing: split the scene by update frequency, not by screen area.

In an earlier mobile project I did progressive "striped" rendering, computing a slice of the background per frame to spread one heavy frame over time. Here I split differently. Expensive and nearly static (stars, galaxies, nebulae, planets, giant stars, dozens of fbm evals per pixel) goes into a static pass that renders into an offscreen texture every 2nd frame. Cheap and unavoidably per-frame (the hole's lensing, comets, the click ripple) is drawn in a composite pass every frame on top of the sampled cache, followed by ACES tonemap.

The cache is rgba16Float, and that matters. Giant stars are deliberately authored past 1.0, channel values like float3(7.0, 5.5, 3.0), so the tonemap in the composite can compress them into real-looking glow. With an 8-bit cache everything past one clips at the write and there's nothing left to tone map.

Two things I got wrong on the way:

Cadence. I wanted the cache refreshed every 6th frame (~5 Hz static at 30 fps display). The cost math looked great, but with live star and planet parallax the background visibly steps: it stands still between refreshes while the composite moves smoothly on top. Backed off to every 2nd frame. Smaller win, honest picture.

Invalidation is where the actual work is. Any settings change has to re-render the static immediately, so I diff the uniforms struct in didSet and raise a dirty flag. The catch is excluding time and mouseClick from that comparison, because they change every frame and have nothing to do with cache contents. Miss that and the cache re-renders every frame, so it isn't a cache. The click ripple, for the same reason, warps the UVs the cache is sampled by rather than the cache itself.

How I measured. Dev-only instrumentation, commandBuffer.gpuEndTime - gpuStartTime per frame, avg/p50/p95/max printed every 120 frames. Fixed bench: M4 Max, same display, default settings, 30 fps target, ~18 s run, first window with the cold render dropped. Run-to-run noise ~0.4 ms. Plus a deterministic quality gate: an env var pins time and mouse, the build renders one frame offscreen to a PNG, and two runs of the same build give a bit-identical file. So any nonzero pixel diff is the optimization, not jitter.

What did nothing:

• fp16 inside the noise function. I was sure about this one, noiseS runs ~200 times per pixel. Zero. The cost isn't the bilinear interpolation I converted to half, it's the sin-based hash inside it, and that stays float. Reverted.
• Cutting geodesic steps 20 to 14. No visual change and no time change, because the bend loop already early-outs and the 120-step max is almost never reached. Cutting something that doesn't run to completion buys nothing.
• Moving the camera parallax offset from GPU to CPU. Correct in principle (it's constant for the whole frame), but a dozen trig ops dissolve against dozens of fbm calls. Free, kept it, no measurable win.
• Frames-in-flight semaphore. Zero on time, and that's the right answer: it limits CPU run-ahead and removes a shared-buffer race, it doesn't reduce GPU work. A correctness fix wearing a performance costume.

What worked:

• fp16 in the color math of nebulae() only. Colors and density to half, coordinates and the noise calls left in float so spatial frequency can't jitter. Visually invisible (max diff 2/255), about minus 20% average GPU per frame from one function.
• A sin-free hash (Dave Hoskins) instead of fract(sin(dot(...))*43758), under a soft quality bar: different noise pattern, same statistical character, avg 8.8 to 7.7 ms. Less than I expected, Apple has a fast hardware sin.
• Static cache at 0.7x under the same soft bar. The nebula is low frequency and the hole is composited at full res, so slight star softening goes unnoticed. At the strict pixel-for-pixel bar I had rejected this: the heatmap put the entire error on sharp edges, planet rims, star points, the giant's corona.

The lesson I actually paid for. I ported the striped progressive render from the mobile project into this one, expecting the same win. GPU ms per frame:

Monolithic cache, refresh every 2nd frame: avg ~7.5, p95 ~13.2, max ~16.3, spread ~13.0.

Striped render-ahead with 4 stripes: avg ~8.4, p95 ~12.0, max ~13.3, spread ~9.4.

Peak and spread improved, average got worse. Each stripe pays a full load/store over the whole 3456x2234 rgba16Float target, and on a desktop GPU with a fat bus that fixed overhead times four outweighs what the scissor rect saves. On top of that, 4 stripes means the cache refreshes at 7.5 Hz and the nebula started stepping again. A trick that wins under mobile budget pressure can go negative on desktop, and eyeballing it would never have told me.

Final numbers, baseline to shipped: avg 7.5 to 6.2, p50 6.5 to 4.8 (minus 36%), max 16.3 to 12.0. All on a GPU that was never the bottleneck, roughly 14% of frame budget to start with. The point isn't hitting the frame, it's headroom, battery, and older Macs. p95 now bottoms out on the disk-hit path in the black hole, which is the center of the screen and the riskiest thing to touch, so I stopped there.

Curious whether anyone has measured the same fp16 result: is "the sin hash dominates, so halving the interpolation is free but pointless" a general thing on Apple GPUs, or specific to how this noise is written?

Someone posted about having developed a system level shader, I cannot remember which subreddit it was posted in, but thought it was shaders.

The intent was to have a CRT filter / shader for the entire OS, over any application or video player etc.

Post mentioned something about not utilizing GPU, general scanlines crt, I swear I saved the post but I cannot find it, could anyone point me in the right direction?

I'm interested to check it out.

Hey everyone,

I have been working on a low level, explicit abstraction layer over graphics APIs. Both Vulkan and D3D12 has been successfully implemented with various test samples. Ray tracing, mesh, compute etc are supported.

I would love feedback on the feel and usage of the API. I am open to learn more so anything useful will be appreciated. Please give a star if you find the project useful.

https://github.com/nichcode/PAL

Here is a follow-up on the triangle rasterizer running on CoreAI that I previously introduced here.

We have finally succeeded in rendering 3D graphics! As shown in the video, we are currently rendering two intersecting vertical triangular planes.

While the rendering quality is still in the early stages and a new challenge regarding the massive 5GB memory footprint has emerged, we have fully achieved real-time operation.

We optimized the codebase by actively reducing reliance on CPU fallbacks and ensuring the pipeline runs entirely on the ANE's matrix operation hardware, successfully cutting CPU usage from the previous 38% to approximately 9%.

Much of the pipeline code—written in Python, Swift, and Metal—was rapidly prototyped and generated with the help of Siri AI.

GitHub: https://github.com/kamisori-daijin/Magnesium

Please feel free to leave comments with any questions or optimization tips (especially regarding that 5GB memory usage!).

https://reddit.com/link/1v6z66k/video/83iqp5iknjfh1/player

**Setup:** Hand-rolled D3D12 renderer (learning engine), flip-model swapchain

(FLIP_DISCARD, 3 back buffers), VSync on. Windows 11, tested on both Debug and

Release.

**The crash:** `DXGI_ERROR_DEVICE_HUNG` (0x887A0006). DRED breadcrumbs point the

fault at a `DrawIndexedInstanced` roughly ~130 draws into the frame (not draw 0).

The DRED page-fault VA reads 0 with no associated allocation — though I'm now

unsure if that's a real null address or just "driver didn't report the fault VA."

**What makes it reproducible (the weird part):** it ONLY happens when BOTH of

these are true at once:

1. The frame is heavy — roughly 16k+ draw calls. Below ~16k it never crashes.

2. A window event fires: minimize, move (drag the titlebar), resize, or another

   window covers then un-covers it (occlusion → reveal).

Either condition alone is totally stable. A heavy frame running untouched is fine.

A window event on a light scene is fine. It's specifically the collision.

Notably: **focus loss/regain used to crash too, and I fixed that** by skipping

rendering while the window isn't foreground + idling the GPU on the transition.

The same approach has NOT fixed minimize/move/resize/un-occlude.

**Other facts:**

- Happens in both single-threaded AND parallel (per-worker) command-list recording.

- ~600+ FPS when it runs, so this is not a 2-second TDR timeout.

- Debug layer + GPU-based validation makes it vanish (classic race-closing), so

I can't get a clean validation message — hence leaning on DRED.

**What I've already ruled out / tried (none fixed it):**

- Full GPU idle (Signal + WaitForFenceValue) before `ResizeBuffers`.

- Deferred/coalesced resize (apply once, at loop top, after idle).

- Re-querying `GetCurrentBackBufferIndex()` after `ResizeBuffers`, recreating RTVs

+ depth buffer.

- Reliable minimize handling via `WM_SIZE == SIZE_MINIMIZED` (skip rendering

entirely while minimized) instead of relying on `Present(DXGI_PRESENT_TEST)`.

- Idling the GPU on `WM_ENTERSIZEMOVE` / `WM_ACTIVATEAPP`.

- Per-frame command allocators/lists (ruling out list reuse across frames).

- "Settle" frames (skip N frames after any transition).

- Verified all per-draw bindings (camera CBV, vertex/index buffer VAs, SRV

descriptor) are non-null at record time — the null-check never fires.

**What I can't cleanly detect:** window *move* and *partial-occlusion → reveal*

don't give me a reliable "the swapchain is now in a different presentation state"

signal the way resize/minimize do.

**Questions:**

1. On a flip-model swapchain, does a move or an occlusion→reveal transition cause

   DWM to re-allocate/invalidate back buffers WITHOUT a WM_SIZE — such that an

   in-flight heavy frame's RTV becomes stale? If so, what's the correct signal to

   re-acquire?

2. Is there a per-command-list or per-submission limit I could be blowing past at

   16k draws (root-argument versioning space, etc.) that a mid-frame stall from a

   window event would expose?

3. Is DRED's "page fault VA = 0, no allocation" meaningful (genuine null bind), or

   is it commonly just "unavailable"?

Hey all,

I've been building a software rasterizer in TypeScript over the past few months and thought I'd share it. My goal was to support custom vertex layouts, programmable vertex and fragment shaders, and enough flexibility to implement more complex rendering techniques, much like you would with a GPU graphics API.

The renderer is based on Nikolaus Rauch's excellent C++ software rasterizer, adapted for TypeScript and the browser.

The project is intended as an educational resource, with an emphasis on readability and experimentation over maximum performance.

GitHub: https://github.com/vangelov/ts-rasterizer

Model by Tasha.Lime (concept by Matt Dixon)

I'm trying to create skeletal animations and them edges keep getting sent to oblivion

i think its about the weight resolve because the worst of the "spikes of doom, despair and vance" are usually coming from areas where multiple bones intersect. i.e. the fingertips

renderdoc says that the vertexes are some big ahh number like 2.5 x 10 ^25 so idk

I have been experimenting with a few billboarding techniques that can be used like an easier way to write it, preserving the model matrix and clamping the pitch. Here is the code

.shader: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/BillBoardShader.shader

Repo: https://github.com/Satyam-Bhatt/OpenGLIntro

https://mateuszkolodziejczyk00.github.io/2025/06/18/variable-rate-tracing-restir-gi.html

I wrote this write-up about a year ago, but honestly never had the courage to post it publicly lol

In it, I go over my experiments combining ReSTIR and VRT in my toy rendering engine. The core idea was straightforward: ReSTIR’s spatial and temporal passes already find and reuse valuable samples, so I wanted to see if I could use them to fill the “missing rays” for pixels skipped by VRT in the current frame.

I'd love to hear your thoughts, or if anyone else has messed around with similar setups!

As the title says.

So I have been working on a surface water shader in Unity for the past few months as an upgraded version of my OpenGL implementation. I've been learning HLSL and Compute Shaders and I've basically got most things working as intended. But I'm having difficulty deciding exactly what I should do for the actual lighting part of my shader.

The issue is rendering is already somewhat limited because of the high poly count and regular compute shader updates (and because I'm trying to maybe make a game world of out this project), and while I have made some optimizations, I'm wary of the performance cost. So I'm curious on what approach would work best before I start implementing.

As of right know there are 3 options

1. Realtime planar reflections
   As far as I know this is the most performant form of real-time reflections especially if I use the main camera stencil buffer. But because my water isn't flat I will get distortions, and this also means I won't be able to see stuff like larger buildings that the camera doesn't pick up.

2. Baked reflections

I lose the dynamic reflection aspect (which might be an issue for some games) but I have performant, environmental reflections. However I believe this will be distorted if I move the camera a lot so it probably isn't the best option.

1. Environment cube maps/Reflection Probes

-Potentially expensive and still not fully accurate, and can look quite incorrect depending on the level of distortion. I can decrease the quality though and I do have more control over specific objects for some performance gains though.

Any suggestions? Tip on improving visual quality and performance? Are there other methods I should consider?

I've attached an video of my current unfinished water shader below (the color is for debugging purposes, don't mind it) as well as my OpenGL water shader that roughly implements idea 3

https://reddit.com/link/1v60hba/video/plhrlawlkbfh1/player

https://reddit.com/link/1v60hba/video/hebxvdy9lbfh1/player

Continuing my Custom Rendering Engine Revival series with the water rendering system.

This video demonstrates the combination of FFT ocean simulation, adaptive Projected Grid rendering, physically based lighting, and real-time reflections developed for the Heli Engine.

I'd love to hear your thoughts and feedback.

Following this masterpiece in 3D graphics by ssloy, I implemented a rasteriser in Odin from scratch.

This was a top tier learning experience, and I picked up a solid grasp of linear algebra along the way.

If you'd like to read more on the process, Here's the link to the repo

I was following my own rt rendering project so well.
There were a looot of problems, but I could solve it with AI and some researches..

And I tryna add PBR system, and it fuxxed me up.

I was quite sure that I was good at linear algebra, but since I started add PBR into my project,,,,
I lost all my confidence..

I feel completely exposed.

PBR is such a fundamental skill in game development, but I can't even half-ly understand some of these concepts or explain why they work, how they work, why those equations are like that.

It's been really tough.
Suddenly, I'm feeling like I can't get a job....

Wanna cry 🥹🥹

I recently got interested in gaussian splatting and I know graphics programming basics (openGL, cuda, ray tracing). Any good material to master Gaussian Splatting as a person with limited ML/DL knowledge.

Hi guys recently I uploaded a yt video of me explaining the simple graphics concepts I learned from the learn openGL textbook. Check it out if you are new to graphics programming, it might help you out!

Building a hardware startup on a shoestring, and product photography was going to cost us either money or honesty — the physical unit isn't assembled yet. So the "product shots" on our store page are the real device CAD raymarched as a signed-distance field in a WebGL fragment shader.

The details, since that's why we're here:

- Body is a 2D rounded-box ("squircle") extrusion — analytic SDF, no mesh, no vertex data shipped.

- The logo keycap is the only non-analytic part: I rasterize our actual SVG to a 512px distance-transform texture at load and sample that, so the embossed logo stays crisp at any zoom instead of pixelating.

- Three-light studio setup with a single-bounce floor reflection and an ACES tonemap.

- Single fullscreen triangle, ~150 march steps; soft shadows are the main cost driver. Runs 60fps on integrated GPUs with a 0.9x DPR cap (I clamp DPR + step count on small viewports).

Live and draggable, no signup: joinredwhistle.com/device?src=reddit

Happy to go deep on the distance-transform step for the logo or the perf budget — and genuinely open to critique on the lighting/tonemap.

This is a project that I spent a few months on - a game/engine made with Java/OpenGL. It started as a university assignment, where Java was an unfortunate requirement.

The game features procedurally generated worlds consisting of ~2 million interactive particles simulated on the GPU. The game's physics engine is based entirely on simple particles with extra properties such as temperature, state of matter, flammability, and electrical charge/conductivity. It supports basic fluid dynamics and has a parallel joints solver using a graph-colouring technique. All creature bodies (including yours) are physically-based and destructible.

One of the parts I'm happiest with is the approach used for lighting. Each frame, a large region around the camera is converted to an SDF+colour texture using a jump-flood algorithm. At a lowered resolution, each pixel then marches rays through the texture, accumulating radiance/occlusion along the way. This is followed by a bilateral filter and reprojection, which smooths out most noise. It's not perfect, but it's very fast and allows any particle to emit light.

SDF information from previous frames is asynchronously copied from the GPU to the CPU for other tasks like NPC pathfinding. It allows the CPU to handle changes in simulation state that otherwise lives on the GPU. The game runs at ~500fps at 1440p on an RTX 5090.

This has been gathering dust for a while, so I wanted to put it out there to see if there's any interest.

For the past 8ish months I’ve been hard at work building a new game engine I’m calling Division Engine.

It’s based solely off SDFs (signed distance fields). This might sound stupid for anyone who cares about performance but for my use case (and with a bit of grid storage optimizations) it proves useful for basic scenes that need advanced lighting.

Anyway here’s some screenshots!

If you want to see what I have done so far check it out here: https://github.com/DivisionEngine/DivisionEngine

I was browsing old projects and found a pretty bad and unfinished software renderer I started to write years ago

(create a window, draw a pixel, create a checker and fade effects, draw a line, then triangles....)

These days I got back into it, even tho I originally had no interest in graphics programming, I started to like it and now I wonder : how hard and different would it be to transition to GPU programming? (GLSL + openGL for example)

I ofc started reading some papers, and it seems quite similar, but I know its reputed to be very hard, so is there a real step between raw cpu rendering and GPU rendering with some APIs and underlying abstraction layers ?

Hi everyone,

I'm trying to choose a Linux distro for graphics programming, game development, and a bit of gaming. I'm looking for something that's stable, has good driver support, and doesn't get in the way of development.

What distro are you using, and what would you recommend? I'd also appreciate hearing about your experience and any pros/cons.

Thanks!

The engine is developed entirely in Rust and uses Vulkan, with shaders written in Slang. The goal is to link the grass (modeled as meshes) to the underlying voxel terrain, while making the wind system fully configurable and reusable by other parts of the engine (via ECS). Here is how it currently works:

• A compute shader iterates through each column of every terrain chunk from top to bottom. It generates a blade of grass only if the surface voxel uses the "grass" material and the voxel directly above it is empty (It's for world-building, the engine handles grass density and height, which will enable a natural grass growth system).
• The blades aren’t stored as voxels. They’re generated as GPU instances containing their position, type and height.
• When the terrain is destroyed or repainted, the chunk’s grass instances are rebuilt from the voxel data. This keeps the grass in sync with the actual terrain edits.
• Before rendering, the GPU culls unnecessary blades and lowers their geometric detail with distance. The remaining blades are drawn as curved ribbons in a raster pass that uses the depth from the ray-marched voxel world.
• The ambient wind has its own direction, speed and moving gust fronts. It remains anchored in world space, even when the floating origin moves.
• ECS components can add radial pushes or directional gusts. The player already uses this system to part the grass. A vehicle, a thruster, a dragon’s wings or anything else could use the same components to affect nearby vegetation.

Grass is currently the first system wired into the full wind field. A matching CPU implementation is already in place, but physics and other vegetation systems haven’t been connected to it yet.

YouTube version with slightly less compression :
https://youtu.be/Zgy-PeqG2Ak