Skip to content

Commit 56be278

Browse files
Fix hightlightjs tags
Change Python to python and Slang to hlsl
1 parent e5b4129 commit 56be278

File tree

1 file changed

+7
-7
lines changed

1 file changed

+7
-7
lines changed

_posts/2025-04-04-neural-gfx-in-an-afternoon.md

+7-7
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ Slang makes this entire process much easier, because it can automatically calcul
4747

4848
Let’s take a look at what it looks like to do this in the code. I’ll first go through a simplified version of the 2D Gaussian splatting example, so it’s very clear how the mechanism works. You can find this example in the SlangPy repository [here](https://github.com/shader-slang/slangpy/tree/main/examples/simplified-splatting). First, we’ll check out the Python side of things. With SlangPy, this code is pretty succinct.
4949

50-
```Python
50+
```python
5151
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
5252

5353
import slangpy as spy
@@ -146,7 +146,7 @@ for iter in range(iterations):
146146

147147
This is the entire Python file for setting up, initializing a set of 2D Gaussian blobs, and kicking off the derivative propagation that calculates the ideal values for all those blob parameters. The setup should be fairly straightforward and explained by the comments, so let’s take a closer look at the “meat” of this file, iterating through our gradient descent.
148148

149-
```Python
149+
```python
150150
iterations = 10000
151151
for iter in range(iterations):
152152
# Back-propagage the unit per-pixel loss with auto-diff.
@@ -164,14 +164,14 @@ What the `module.perPixelLoss.bwds()` call is doing is going into the Slang modu
164164

165165
When this call finishes, per_pixel_loss will contain values representing the results of the loss function for each pixel based on the “calculated image” that results from all of our current blob parameters, and blobs will have a gradient associated with each blob, indicating which direction the parameters should move in order to get closer to the target. The input image will be unchanged.
166166

167-
```Python
167+
```python
168168
# Update the parameters using the Adam algorithm
169169
module.adamUpdate(blobs, blobs.grad_out, adam_first_moment, adam_second_moment)
170170
```
171171

172172
This line calls into a Slang function in our module which provides an [optimized algorithm](https://optimization.cbe.cornell.edu/index.php?title=Adam) for updating our blobs based on the information stored in the blob gradients. It calculates moving averages of these gradients, so that we can update our blob parameters efficiently. You can read more about how Adam works in [the paper](https://arxiv.org/pdf/1412.6980) that introduced it, and you’ll see the implementation in our Slang module in a moment. Don’t worry– it’s less than thirty lines of Slang code!
173173

174-
```Python
174+
```python
175175
# Every 50 iterations, render the blobs out to a texture, and hand it off to tev
176176
# so that you can visualize the iteration towards ideal
177177
if iter % 50 == 0:
@@ -188,7 +188,7 @@ Ok! Now, for the Slang side of things.
188188

189189
There’s a bit more to the Slang code, but let’s first take a look at the functions that we called out to from SlangPy just a moment ago. The workhorse of the module is that `perPixelLoss()` function and its helpers:
190190

191-
```Slang
191+
```hlsl
192192
// simpleSplatBlobs() is a naive implementation of the computation of color for a pixel.
193193
// It will iterate over all of the Gaussians for each pixel, to determine their contributions
194194
// to the pixel color, so this will become prohibitively slow with a very small number of
@@ -272,7 +272,7 @@ You might wonder if iterating over our entire list of Gaussians for each pixel i
272272

273273
This set of functions is responsible for calculating all of the output pixels, as well as the difference between those values and our ideal target image, so they’re invoked not just for propagating loss derivatives (the `module.perPixelLoss.bwds` call we made in Python), but also during the rendering of our output texture, via `renderBlobsToTexture`, which looks like this:
274274

275-
```Slang
275+
```hlsl
276276
void renderBlobsToTexture(
277277
    RWTexture2D<float4> output,
278278
    GradInOutTensor<float, 1> blobsBuffer,
@@ -288,7 +288,7 @@ As you can see, this function just takes the result of `simpleSplatBlobs`, and w
288288

289289
The other piece of the equation is the Adam update algorithm:
290290

291-
```Slang
291+
```hlsl
292292
void adamUpdate(inout float val,
293293
inout float dVal,
294294
inout float firstMoment,

0 commit comments

Comments
 (0)