1951346857017250014, 1990260050485797063

2026-08-25 11:16:05 -04:00
1 parent bb4a46a847
commit 1f87a7aaeb
@@ -0,0 +1,65 @@
+---
+title: "elaborate on the \"CART\"-style memory model?"
+type: archive
+source: twitter
+source_url: "https://x.com/VPCOMPRESSB/status/1951359238787186957"
+author: "/i:'mɪər/"
+handle: VPCOMPRESSB
+post_id: "1951359238787186957"
+date: 2025-08-01
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "elaborate on the \"CART\"-style memory model?"
+in_reply_to: ""
+parent_post_id: "1951346857017250014"
+---
+
+## Source
+
+- URL: https://x.com/VPCOMPRESSB/status/1951359238787186957
+- Author: /i:'mɪər/ (@VPCOMPRESSB)
+- Posted: 2025-08-01 19:07:51
+
+## Branch
+
+**1/**
+
+elaborate on the "CART"-style memory model?
+
+i assume you initialize with the default start-up state that's maybe loaded from disk into a static buffer (the "CART"). you read from the CART, then perform transformations in a separate region of [dynamic] memory (the pool), and periodically copy data from the pool back into the CART (the snapshots)?
+
+saving the game would then just be copying a region to disk contiguously—zero fragmentation. which means you can stream-in data linearly, provided that the layout of the CART maps to the ordering of the transformation stages. you can also compress the data in the CART quiet well i imagine. you can implement this as a double buffering system? the CART used strictly for rendering, and the pool strictly for transformations?
+
+**2/**
+
+@VPCOMPRESSB There is a Vulkan extension on PC that enables one to take a mapped file (aka the page cache) and access it from the GPU directly.
+
+**3/**
+
+@NOTimothyLottes @VPCOMPRESSB @VPCOMPRESSB I believe the benefit here is that it avoids an extra copy.
+
+https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_external_memory_host.html
+
+**4/**
+
+@AgileJebrim @NOTimothyLottes that API seems very opaque. how can a person tell/preset the size and behavior of the page cache? would i just need to manage it similar to managing the CPU's cache?
+
+**5/**
+
+@VPCOMPRESSB @NOTimothyLottes There’s a win32 version too but yeah I would just generally assume that pages are 4096 bytes unless I have reason to believe otherwise. Apparently the intent that Timothy had is to use CreateFileMappingA() as well.
+
+**6/**
+
+@AgileJebrim @VPCOMPRESSB In an ideal world the OS would allow pinning the file's pages. Since there is no guarantee, I can walk (read) the first cache line of the 4 kb pages periodically to try to force pinned behavior.
+
+**7/**
+
+@NOTimothyLottes @VPCOMPRESSB VirtualLock()?
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the]]
@@ -35,6 +35,8 @@ Branches: [[archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-h

 It won't require RT, but it also won't run on Intel iGPUs [to low binding limits, etc]. Memory model will be 'CART' style where you get the a RAM CART [buffer] in memory which gets state snapshot, followed by dynamic GPU memory which is not snapshotted

+Branches: [[archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume]]
+
 **3/**

 Also run-from GPU-side editing tools for shader source and bind everything tables. And build-the-editors-in-it style. Which load/store to the CART. So it won't be for people who want TBs of giant team gen content, but rather sized for what a single person could pull off
@@ -7,7 +7,7 @@ author: "Ben Golus⚠️⭕"
 handle: bgolus
 post_id: "1990285316054503566"
 date: 2025-11-17
-archived: 2026-08-23
+archived: 2026-08-25
 draft: true
 tags:
  - archive
@@ -7,7 +7,7 @@ author: "Dmitrii Terekhov"
 handle: terekhov_de
 post_id: "1990284522508927371"
 date: 2025-11-17
-archived: 2026-08-23
+archived: 2026-08-25
 draft: true
 tags:
  - archive
@@ -7,7 +7,7 @@ author: "Alec Miller"
 handle: Alecazam123
 post_id: "1990818990059671922"
 date: 2025-11-18
-archived: 2026-08-23
+archived: 2026-08-25
 draft: true
 tags:
  - archive
@@ -7,7 +7,7 @@ author: "Yuriy Stets"
 handle: stainless_code
 post_id: "1991219165978370275"
 date: 2025-11-19
-archived: 2026-08-23
+archived: 2026-08-25
 draft: true
 tags:
  - archive
@@ -7,7 +7,7 @@ author: "NOTimothyLottes"
 handle: NOTimothyLottes
 post_id: "1990260050485797063"
 date: 2025-11-17
-archived: 2026-08-23
+archived: 2026-08-25
 draft: false
 tags:
  - archive
@@ -30,4 +30,19 @@ in_reply_to: ""
 I wish everyone would just adopt "reversed with infinite far" projection matrixes so I could only optimize for the fastest and highest precision option, but I'm guessing people haven't all migrated over :(

 ![](https://pbs.twimg.com/media/G57SXPJW8AAvEhh?format=png&name=orig)
-Branches: [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-AgileJebrim-reversed-is-a-significant-improvement-but-it]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive]]
+
+Branches: [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive]]
+
+**2/**
+
+Reversed is a significant improvement but it still has its limitations when doing planetary-scale rendering that needs good precision up both close and far away. Your options there are either a logarithmic depth buffer to linearize things (albeit losing early z), your own integer-based depth test system in compute shaders, or a stack of multiple frustums layered on top of one another.
+
+**3/**
+
+@AgileJebrim Yes for my non-tri stuff I'm log depth already. This is just for games, not simulation.
+
+**4/**
+
+Simulation can usually localize enough that reverse Z is good enough. Google Earth style geospatial visualization is where things get trickier.
+
+Another option is to dynamically change the far plane, moving it closer as you get closer to the terrain and further back as you move further back. I don’t think I tried this one but I imagine it requires a lot of tuning.