Private
Public Access
50 lines
2.8 KiB
Markdown
50 lines
2.8 KiB
Markdown
← [Back to Twitter thread index](../README.md)
|
|
|
|
---
|
|
title: "After VK device is open, I signal a background thread to load the SPIR-V module,"
|
|
author: "NOTimothyLottes"
|
|
handle: "@NOTimothyLottes"
|
|
post_url: "https://x.com/NOTimothyLottes/status/1858715434436227544"
|
|
post_id: "1858715434436227544"
|
|
timestamp: "2024-11-19 03:34:27"
|
|
post_count: 8
|
|
reply_count: 0
|
|
repost_count: 0
|
|
like_count: 2
|
|
view_count: 424
|
|
---
|
|
|
|
# @NOTimothyLottes — After VK device is open, I signal a background thread to load the SPIR-V module,
|
|
|
|
## Post 1 (2024-11-19 03:10:28)
|
|
|
|
Working towards a new bring up of front-buffering on NV via VK. My last implementation had been tuned on AMD and didn't work on NV any more. NV does seem to accept a 1-deep swap with IMMEDIATE presentation at least on latest drivers, so that is a good start.
|
|
|
|
## Post 2 (2024-11-19 03:13:21) — reply to Post 1
|
|
|
|
Since my image resources are static after init time, only swap images change when the driver kills the swap chain (which once upon a time seemed to happen on ALT+TAB maybe). So it's one descriptor set always bound.
|
|
|
|
## Post 3 (2024-11-19 03:15:43) — reply to Post 2
|
|
|
|
Stopped using VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT (god awful naming length people), because I think it could be a perf hit on NV due to extra indirection. NV driver is free to bake down the single set now before the command buffer is sent over.
|
|
|
|
## Post 4 (2024-11-19 03:21:26) — reply to Post 3
|
|
|
|
At this stage, to the point of having everything loaded and swap chain created, it's 2700 lines of engine code. That includes embedding headers (no external includes), so it's a one file compile. People claim rolling your own engine is hard? Not really if you keep it focused.
|
|
|
|
## Post 5 (2024-11-19 03:26:46) — reply to Post 4
|
|
|
|
So far it's a 0.25 sec hot load time on this NV dGPU laptop. Includes mapping a 4 MiB 'cart' file from pagecache, doing a 512 MiB buffer for GPU usage, hits on all PSOs, allocating some images, and kicking the command buffer that copies in the cart, and clears everything.
|
|
|
|
## Post 6 (2024-11-19 03:29:11) — reply to Post 5
|
|
|
|
Everything at load-time is multi-threaded to try to minimize start to in-game time. This is in sharp contrast to runtime where the only multi-threading being used is to separate things that are blocking.
|
|
|
|
## Post 7 (2024-11-19 03:32:22) — reply to Post 6
|
|
|
|
I get some utility on parallelizing {vulkan instance creation, mapping the cart file, warming the TLBs by walking all the pages, bringing up the window} it's about 0.08 seconds in at that point
|
|
|
|
## Post 8 (2024-11-19 03:34:27) — reply to Post 7
|
|
|
|
After VK device is open, I signal a background thread to load the SPIR-V module, while building the descriptor set layout, which then unblocks PSO compile on background threads. And the rest of the VK setup runs in parallel. Working towards swap creation.
|