1737845233067630738, 1737618231450579351, 1737499394633560366
This commit is contained in:
ed committed
1 parent
872e376951
commit
6bcfdcf366
6 files changed
+258
No files matched your search
+38
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Before moving all GPU-side, I had source recompile while running."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1737499394633560366"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1737499394633560366"
|
||||
date: 2023-12-20
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Before moving all GPU-side, I had source recompile while running."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1737499394633560366
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2023-12-20 15:45:11
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** **@NOTimothyLottes** ^1737499394633560366
|
||||
|
||||
Before moving all GPU-side, I had source recompile while running. I'd place all global data in one structure, and pass that pointer to the DLL/SO on reload. This was done via self-including to make code layout easy. I still do that practice today:
|
||||
|
||||
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1737500234870067342
|
||||
|
||||
Using {DEF_,TYP_,RAM_,ROM_} defines to denote what pass of the self include to place the code in. So anything in RAM_ for example gets dumped into the global data structure. Nice for keeping code concept locality in the source.
|
||||
|
||||
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: "@NOTimothyLottes It is a gray driver area."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/frustum/status/1737629120492912667"
|
||||
author: "Alexander Zapryagaev"
|
||||
handle: frustum
|
||||
post_id: "1737629120492912667"
|
||||
date: 2023-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes It is a gray driver area."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1737618231450579351"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/frustum/status/1737629120492912667
|
||||
- Author: Alexander Zapryagaev (@frustum)
|
||||
- Posted: 2023-12-21 00:20:40
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** **@frustum** ^1737629120492912667
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
It is a gray driver area. Having this feature on all GPUs would be awesome. However, it will face a serious problem known as the 4GB SSBO size limitation.
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1737631902725537866
|
||||
|
||||
**@frustum**
|
||||
|
||||
Sure, but even for <4GiB it would be useful. However I doubt it actually works at all, because it implies page locking parts of the page cache. I'm trying just 2 MiB thus far and have not got it working. But it's Vulkan, so any number of other stupid things could go wrong.
|
||||
|
||||
**3/** **@frustum** ^1737634564938543253
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
Our cross-GPU buffer mapping works properly. I will try to import a memory mapped file on Linux and Windows tomorrow.
|
||||
|
||||
**4/** **@frustum** ^1737743235769114667
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
It's working pretty well with:
|
||||
Nvidia DGPU Windows/Linux - ok (RW mmap)
|
||||
AMD DGPU/IGPU Windows - ok (RW mmap)
|
||||
Apple (Metal) - ok (R and RW mmap)
|
||||
|
||||
**5/** **@never_released** ^1737796103712497921
|
||||
|
||||
**@frustum** **@NOTimothyLottes**
|
||||
|
||||
Note that host pinned mem is not cacheable on the GPU side though.
|
||||
|
||||
On Linux w/ NVIDIA dGPUs you can also have HMM, but that’s not leverageable on gfx APIs
|
||||
|
||||
**6/** **@NOTimothyLottes** ^1737807709926281372
|
||||
|
||||
**@never_released** **@frustum**
|
||||
|
||||
Certainly didn't translate that one. By "not cacheable on GPU" -> {read is a forced miss, and store through the bus}? Just wondering, why would an app provided address mapping require a different GPU page mapping cache policy than a driver address mapping?
|
||||
|
||||
**7/** **@never_released** ^1737808182204919927
|
||||
|
||||
**@NOTimothyLottes** **@frustum**
|
||||
|
||||
It's because PCIe isn't quite a coherent interconnect, so the way to achieve coherency on it w/o page migration is to have memory accesses be uncached on the remote side (the one that doesn't have the data in its local memory).
|
||||
|
||||
**8/** **@NOTimothyLottes** ^1737811922722996266
|
||||
|
||||
**@never_released** **@frustum**
|
||||
|
||||
Still missing something, or my knowledge is wrong: standard VK driver practice on host-side-allocations is GPU hit-on-read. Because: 4k pass = around 128k 8x8 workgroups, if loading a constant from a host-side-allocation, with miss-on-read that's 128k misses to the same address
|
||||
|
||||
**9/** **@NOTimothyLottes** ^1737813509189071350
|
||||
|
||||
**@never_released** **@frustum**
|
||||
|
||||
... only coherency GPU sees on host allocations normally is at cache write-back and invalidate boundaries (explicit in command, or implicit post/pre-amble). So back to question: why would a driver force special uncached behavior for {app supplied pointer}, (vs) {driver mapping}?
|
||||
|
||||
**10/** **@never_released** ^1737819525712671027
|
||||
|
||||
**@NOTimothyLottes** **@frustum**
|
||||
|
||||
> ... only coherency GPU sees on host allocations normally is at cache write-back and invalidate boundaries […]
|
||||
|
||||
Not applicable to use of VkImportMemoryHostPointerInfoEXT on multiple drivers that I know of, where it’s just a straight map over PCIe.
|
||||
|
||||
**11/** **@NOTimothyLottes** ^1737820845932687825
|
||||
|
||||
**@never_released** **@frustum**
|
||||
|
||||
Certainly some mini-profiling is in order to verify what actual driver behavior is
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2023-12-20-curious-if-you-can-mapviewoffile-and-then-use]]
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "@NOTimothyLottes Loading files would be synchronous and involve a bunch of faults, so how would it be worth it compared to the syscall overhead?"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/vladov3000/status/1737631747750109607"
|
||||
author: "vlad vladov"
|
||||
handle: vladov3000
|
||||
post_id: "1737631747750109607"
|
||||
date: 2023-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes Loading files would be synchronous and involve a bunch of faults, so how would it be worth it compared to the syscall overhead?"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1737618231450579351"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/vladov3000/status/1737631747750109607
|
||||
- Author: vlad vladov (@vladov3000)
|
||||
- Posted: 2023-12-21 00:31:06
|
||||
|
||||
## Branch
|
||||
|
||||
**1/** **@vladov3000** ^1737631747750109607
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
Loading files would be synchronous and involve a bunch of faults, so how would it be worth it compared to the syscall overhead?
|
||||
|
||||
**2/** **@NOTimothyLottes** ^1737632532357636356
|
||||
|
||||
**@vladov3000**
|
||||
|
||||
It would have to pre-fault the pages and lock the pages to have a GPU mapping of it. It would be worth it to not have to use some other mechanism for the GPU program to feed the CPU information about what to copy out of GPU memory into a file.
|
||||
|
||||
**3/** **@vladov3000** ^1737649307736821760
|
||||
|
||||
**@NOTimothyLottes**
|
||||
|
||||
I see.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2023-12-20-curious-if-you-can-mapviewoffile-and-then-use]]
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Curious if you can MapViewOfFile() and then use VkImportMemoryHostPointerInfoEXT to map that R+W on the GPU."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1737618231450579351"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1737618231450579351"
|
||||
date: 2023-12-20
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Curious if you can MapViewOfFile() and then use VkImportMemoryHostPointerInfoEXT to map that R+W on the GPU."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1737618231450579351
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2023-12-20 23:37:24
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** **@NOTimothyLottes** ^1737618231450579351
|
||||
|
||||
Curious if you can MapViewOfFile() and then use VkImportMemoryHostPointerInfoEXT to map that R+W on the GPU. Anyone try it?
|
||||
|
||||
If it worked, one could then support shader load/store to a WAD file 'on disk' (aka page cache) without ever involving syscalls to access.
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2023-12-20-curious-if-you-can-mapviewoffile-and-then-use/2023-12-21-frustum-it-is-a-gray-driver-area-having-this-feature-on]], [[archive/threads/NOTimothyLottes/2023-12-20-curious-if-you-can-mapviewoffile-and-then-use/2023-12-21-vladov3000-loading-files-would-be-synchronous-and-involve-a]]
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Code shy brain says it's strange to be reading your source in a public git during beta period before anything launches using it, but this is the new way apparently."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1737845233067630738"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1737845233067630738"
|
||||
date: 2023-12-21
|
||||
archived: 2026-08-26
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Code shy brain says it's strange to be reading your source in a public git during beta period before anything launches using it, but this is the new way apparently."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1737845233067630738
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2023-12-21 14:39:25
|
||||
|
||||
## Thread
|
||||
|
||||
**1/** **@NOTimothyLottes** ^1737845233067630738
|
||||
|
||||
Code shy brain says it's strange to be reading your source in a public git during beta period before anything launches using it, but this is the new way apparently. Like all betas, feedback-improve loop from 1st actual integrations is important. If you try STP, ping me :)
|
||||
@@ -30,6 +30,9 @@ tags:
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-19-working-towards-a-public-domain-release-of-a]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-20-another-bad-habit-i-dont-include]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-20-before-moving-all-gpu-side-i-had-source-recompile]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-20-curious-if-you-can-mapviewoffile-and-then-use]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-21-code-shy-brain-says-its-strange-to-be-reading]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-25-virtualized-xmas-thread]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-26-no-luck-getting-d3dkmtgetscanline-to-work-thus-far]]
|
||||
- [[archive/threads/NOTimothyLottes/2023-12-29-end-of-2023-scaling-parallel-gfx-and-memory-thread]]
|
||||
|
||||
Reference in new issue
Block a user