1
1
# devlog
2
2
3
+ ## Mon June 17, 2024
4
+
5
+ ### nlnet updates
6
+
7
+ The [ first nlnet milestone PR] ( https://github.com/gfx-rs/wgpu/pull/5775 ) is really close to
8
+ merging. I'm already working on the [ follow up PR] ( https://github.com/gfx-rs/wgpu/pull/5824 )
9
+ that adds the rest of the operators, which is milestone #2 .
10
+
3
11
## Sun June 16, 2024
4
12
5
13
### nlnet updates
@@ -12,6 +20,23 @@ What this means is that I'm actually very close to hitting the first nlnet miles
12
20
With that, I've started work on the second milestone while my first set of PRs are in review,
13
21
as it takes a good while to roundtrip w/ feedback.
14
22
23
+ #### Spiralling out
24
+
25
+ Previously we had talked about upgrading expressions, and how there would be a "spiralling out"
26
+ or "cascade" of upgrades needed. I think we've mostly side-stepped that requirement by first
27
+ realizing that atomics can really only be held in global variables since they only appear in
28
+ ` workgroup ` and ` storage ` address spaces.
29
+
30
+ So these ops will always be accessed through a pointer to a global variable, and we can modify
31
+ that global variable's type in place and then not worry about having to upgrade the expressions
32
+ that contain that global variable. It's a nice simplification.
33
+
34
+ > The reason I think you won't need to update any expressions is that Naga IR Load expressions
35
+ > and Store statements both can operate on Atomics, so everything accessing the globals whose
36
+ > types you're whacking, whether Loads, Stores, or Atomics, should still be okay.
37
+ >
38
+ > -- Jim Blandy
39
+
15
40
### raspberry pi updates
16
41
17
42
Still getting OOM errors and I'm not sure why. There are a few changes I need to make to figure
@@ -36,6 +61,7 @@ it out:
36
61
![ diff] ( https://github.com/schell/renderling/assets/24942/4770e596-34ee-479f-ba2d-2325d8dfa282 )
37
62
38
63
` seen.png ` is nothing but wacky garbage!
64
+
39
65
## Fri June 14, 2024
40
66
41
67
### nlnet updates
0 commit comments