1953820468697317627 1736217482682138685 1736232422528709002

2026-08-25 00:26:28 -04:00
1 parent ded6789bfa
commit 758d36dcd8
@@ -0,0 +1,39 @@
+---
+title: "@NOTimothyLottes Yep put the whole game logic in a game.glsl compute shader."
+type: archive
+source: twitter
+source_url: "https://x.com/AgileJebrim/status/1736232422528709002"
+author: "Jebrim"
+handle: AgileJebrim
+post_id: "1736232422528709002"
+date: 2023-12-17
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes Yep put the whole game logic in a game.glsl compute shader."
+in_reply_to: ""
+parent_post_id: "1736157335058300999"
+---
+
+## Source
+
+- URL: https://x.com/AgileJebrim/status/1736232422528709002
+- Author: Jebrim (@AgileJebrim)
+- Posted: 2023-12-17 03:50:41
+
+## Branch
+
+**1/**
+
+@NOTimothyLottes Yep put the whole game logic in a game.glsl compute shader.
+
+**2/**
+
+If doing a large open world game, set up a paging system to stream data to the GPU in tiles, particularly static data. All dynamic data should be handled on the GPU. If leveraging  server, you can pass along the network packets as they are. CPU shouldn’t really be doing much for a game client. It certainly shouldn’t be varying due to scene complexity.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it]]
@@ -0,0 +1,53 @@
+---
+title: "@NOTimothyLottes two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms.."
+type: archive
+source: twitter
+source_url: "https://x.com/SheriefFYI/status/1736217482682138685"
+author: "Sherief, FYI"
+handle: SheriefFYI
+post_id: "1736217482682138685"
+date: 2023-12-17
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms.."
+in_reply_to: ""
+parent_post_id: "1736147815829565624"
+---
+
+## Source
+
+- URL: https://x.com/SheriefFYI/status/1736217482682138685
+- Author: Sherief, FYI (@SheriefFYI)
+- Posted: 2023-12-17 02:51:19
+
+## Branch
+
+**1/**
+
+@NOTimothyLottes two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms..
+
+**2/**
+
+@SheriefFYI Yeah and that's a warm second run too. I dev on crippled laptops so when the handicaps are removed the stuff really flies.
+
+**3/**
+
+@NOTimothyLottes still that sounds like a lot, what specs / driver? Any weird vk layers loading?
+
+**4/**
+
+@SheriefFYI Ok, yeah just reprofiled, and it's down to 269 ms. Best part of the Win10 experience, never know what is actually happening in the background.
+
+![](https://pbs.twimg.com/media/GBhSG-XXMAAT0FS?format=png&name=orig)
+
+**5/**
+
+@NOTimothyLottes *whew* that sounds more normal
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it]]
@@ -0,0 +1,77 @@
+---
+title: "@NOTimothyLottes so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?"
+type: archive
+source: twitter
+source_url: "https://x.com/VPCOMPRESSB/status/1953820468697317627"
+author: "/i:'mɪər/"
+handle: VPCOMPRESSB
+post_id: "1953820468697317627"
+date: 2025-08-08
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?"
+in_reply_to: ""
+parent_post_id: "1736154923408953499"
+---
+
+## Source
+
+- URL: https://x.com/VPCOMPRESSB/status/1953820468697317627
+- Author: /i:'mɪər/ (@VPCOMPRESSB)
+- Posted: 2025-08-08 14:07:54
+
+## Branch
+
+**1/**
+
+@NOTimothyLottes so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?
+
+if this is the case, the program identifier makes sense. you can just swap out the code, leaving the data untouched.
+
+**2/**
+
+@VPCOMPRESSB I use the layout aliasing to choose things like {read-only K$ reads, vs read-write texture cache access} for buffers, for making sure GLC=1 (write through to coherent cache domain) is enabled for stores (image and buffer), as well as selecting the texel format for image access :)
+
+**3/**
+
+i revisited last night.
+
+e.g.
+
+i heard that a single shader doesn't like using multiple images due to resource contention.
+
+i assume your code is laid in stages. each stage corresponds to a specific image. barriers are emplaced between stages. essentially, in a single shader, you'd imitate multiple shaders that are pipelined.
+
+aliasing supports this even further, with explicit intentions for resources.
+
+**4/**
+
+@VPCOMPRESSB On modern desktop GPUs it is very efficient to have everything bound all the time (bind everything once/frame). On AMD on use the descriptor is loaded into SGPRs. You only pay for what is used. And ideally group descriptors used together near so they share same cache lines.
+
+**5/**
+
+@VPCOMPRESSB Merging independent shaders is then easy. Merging dependent shaders is more complex. You can both do it an unsafe way or a safe way (too long for one tweet)...
+
+**6/**
+
+@VPCOMPRESSB The unsafe way: launch a N+M sized 1D dispatch. Bank on having enough work in N such that when the dependent M starts that enough of N is finished in practice. This can work when early M depends on only early N workgroups.
+
+**7/**
+
+@VPCOMPRESSB There are various safe ways. For instance  if the dependent work isn't done, one can conditionally duplicate the work. Or conditionally use a fallback. Or only use the pre task if it had finished to accelerate the second, for example hierarchical empty space skipping ...
+
+**8/**
+
+@VPCOMPRESSB The challenge of course is that the  obvious stuff like spin waiting isn't safe because of bad API and driver design : no forward progress guarantee (on preemption, etc)
+
+**9/**
+
+@VPCOMPRESSB Quite literally they just need to put in a guarantee that workgroups with lower coords in scan order are launched first and restored first in a partial preemption restore. Then you could safely spin on work in a prior numbered workgroup
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it]]
@@ -7,8 +7,8 @@ author: "NOTimothyLottes"
 handle: NOTimothyLottes
 post_id: "1736147815829565624"
 date: 2023-12-16
-archived: 2026-08-23
-draft: true
+archived: 2026-08-25
+draft: false
 tags:
  - archive
  - twitter
@@ -30,41 +30,55 @@ in_reply_to: ""
 Inspecting my old VK engines. On start I would warm all the pages. Code pages get a read, and data pages got an atomic add of a non-compiler known zero. An attempt to improve initial load time. But in the end nothing helps the 2.6 seconds or so required to just open the VK device

 ![](https://pbs.twimg.com/media/GBgHT_2WIAAKuNq?format=png&name=orig)
+
+Branches: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my]]
+
 **2/**

 Since I almost never get crashes I forgot about this, but had written a system to auto relaunch the app on crash or special case exit. No complex error handling, just bank on fast relaunch instead.

 ![](https://pbs.twimg.com/media/GBgJ1y5W0AArwSt?format=png&name=orig)
+
 **3/**

 The hope of single PSO in VK was scrapped because IHV compile times explode. However I did maintain single SPIR-V file, and use spec constants to choose individual shaders. The threads doing compile dump compile times and disassembly in DEV mode.

 ![](https://pbs.twimg.com/media/GBgMbMEWkAAOd_d?format=png&name=orig)
+
 **4/**

 I'm a fan of single file applications. So when not in DEV mode the one SPIR-V file gets pulled from the EXE. Compiling PSOs is always the critical path, the moment the "bind everything once" layout is done, PSO compile goes wide on the machine.

 ![](https://pbs.twimg.com/media/GBgOQRiXoAAX2k6?format=png&name=orig)
+
 **5/**

 "Bind-Everything-Once" in Vulkan looks like this. Bindings {1}=CPU pushing to GPU, {2}=buffer (more on that next), {3}=as UAVs, {4}=as TEX ... No binding logic at runtime ever. Access anything in the most efficient way any time.

 ![](https://pbs.twimg.com/media/GBgPDhAWUAAzhEi?format=png&name=orig)
+
+Branches: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor]]
+
 **6/**

 Did something silly but fast for buffers. Here is an example from a dummy test app. The main SSBO gets aliased as 4 structures, each with the same data accessable with four types {uint, uint4, float, float4}. So same binding layout aliasing chooses load type and K$ or V$ access.

 ![](https://pbs.twimg.com/media/GBgQ0xlWQAA7Yks?format=png&name=orig)
+
 **7/**

 Literally the CPU does almost nothing. All game input gets pushed to the GPU for game logic. Some major advantages in input latency to do player logic on the GPU instead. And it's dead easy.

 ![](https://pbs.twimg.com/media/GBgRu3wXoAAp_K7?format=png&name=orig)
+
+Branches: [[archive/threads/NOTimothyLottes/2023-12-16-if-there-is-anything-to-learn-for-programming-it/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl]]
+
 **8/**

 This requires context, I build programs in a hardware style, fixed resources, fixed shaders, and all logic expressed in the data itself. No code or resource variation, no runtime issues period. So another dummy program example, I can just list my resources on load in a table ...

 ![](https://pbs.twimg.com/media/GBgTCgJXsAEPH3W?format=png&name=orig)
+
 **9/**

 Radically simplicity is how I roll personally. Easy to confuse the idea that one needs complexity to express a complex system. It's more like one needs complexity to express a complex solution -> abstractions and hierachical meta feeds on itself until tech debt freezes progess.