Linux, NVIDIA's driver: every start logs `NVRM: memMap_IMPL: CPU mapping not supported`, because the driver refuses the game's dma-buf imports #2339

Closed

opened 2026-11-11 15:15:28 +00:00 by mooki000 · 1 comment

mooki000 commented

2026-11-11 15:15:28 +00:00

(Migrated from github.com)

Hookshot version

main 49f75dc8 and bdfe09c, built from source

What kind of problem

Something else

What happened

On Linux with NVIDIA's driver the kernel log gets NVRM: memMap_IMPL: CPU mapping not supported for addressSpace: 0x1 at every start of the game, sometimes again later in a run. It reads like a driver fault and is not one.

The cause: the game asks the driver to import every block of guest memory as a udmabuf dma-buf (#448, which helps AMD with RADV). NVIDIA's driver offers two memory types for such a dma-buf; the code takes the host-visible one, and the driver refuses that import for every pool (vk: guest ...: its dma-buf not imported (VkResult -2)). Each pool then goes through the host-pointer import, which works. So on NVIDIA the dma-buf route never carries a pool: it only adds a failed attempt in front of each one, 49 to 50 in a 90-second run, and the kernel prints its line for some of them.

Expected: no refused imports and no kernel line.

Where in the game

Every start; counted in Kokiri Forest from a save

How often

Every time

Graphics card and driver version

RTX 4090, NVIDIA 615.78.08 (open kernel module)

CPU, RAM and operating system

i9-13900K, 96 GB, Arch Linux (kernel 7.2.15)

Changes from the defaults

None

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

The lines that show it: vk: guest memory as dma-bufs: yes followed by its dma-buf not imported (VkResult -2) for each pool, and in the kernel log the line above.

Claim

I'm working on this: #2340 is open with the fix and its test. It belongs under #1000. By docs/workflow.md: S3 (1), a cleanup of the start and the log, since I measured no frame-rate difference; reach: Linux players on NVIDIA's driver (Tier 1); confidence 1.0 on this card and driver, untested on others. I can test on Linux with an RTX 4090 (NVIDIA 615.78.08) and an Intel UHD 770 (Mesa 26.2.5), not on Windows or AMD.

### Hookshot version main 49f75dc8 and bdfe09c, built from source ### What kind of problem Something else ### What happened On Linux with NVIDIA's driver the kernel log gets `NVRM: memMap_IMPL: CPU mapping not supported for addressSpace: 0x1` at every start of the game, sometimes again later in a run. It reads like a driver fault and is not one. The cause: the game asks the driver to import every block of guest memory as a udmabuf dma-buf (#448, which helps AMD with RADV). NVIDIA's driver offers two memory types for such a dma-buf; the code takes the host-visible one, and the driver refuses that import for every pool (`vk: guest ...: its dma-buf not imported (VkResult -2)`). Each pool then goes through the host-pointer import, which works. So on NVIDIA the dma-buf route never carries a pool: it only adds a failed attempt in front of each one, 49 to 50 in a 90-second run, and the kernel prints its line for some of them. Expected: no refused imports and no kernel line. ### Where in the game Every start; counted in Kokiri Forest from a save ### How often Every time ### Graphics card and driver version RTX 4090, NVIDIA 615.78.08 (open kernel module) ### CPU, RAM and operating system i9-13900K, 96 GB, Arch Linux (kernel 7.2.15) ### Changes from the defaults None ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt The lines that show it: `vk: guest memory as dma-bufs: yes` followed by `its dma-buf not imported (VkResult -2)` for each pool, and in the kernel log the line above. ### Claim I'm working on this: #2340 is open with the fix and its test. It belongs under #1000. By `docs/workflow.md`: S3 (1), a cleanup of the start and the log, since I measured no frame-rate difference; reach: Linux players on NVIDIA's driver (Tier 1); confidence 1.0 on this card and driver, untested on others. I can test on Linux with an RTX 4090 (NVIDIA 615.78.08) and an Intel UHD 770 (Mesa 26.2.5), not on Windows or AMD.

CIB commented

2026-11-11 15:53:32 +00:00

(Migrated from github.com)

Second datapoint on a different driver: RTX 4090, NVIDIA 590.48.01 (open kernel module), Arch Linux, kernel 6.19.8, Vulkan 1.4. On stock main 8c92fe3, three starts: every start logs its dma-buf not imported (VkResult -2) (7 lines on a first start, 1 on the next two) and adds exactly one NVRM: memMap_IMPL: CPU mapping not supported for addressSpace: 0x1 to the kernel log. The pools then import as host pointers and the game reaches its first decoder. So this is not specific to 615.78.08.

With #2340's vk_memory.cpp hunk applied here, two starts: no VkResult -2, no new memMap_IMPL, and vk: guest memory as dma-bufs: no (NVIDIA's driver refuses them: host pointers). I have not measured frame times.

🤖 Generated with opencode using DeepSeek V4.1 Flash.

Second datapoint on a different driver: RTX 4090, NVIDIA **590.48.01** (open kernel module), Arch Linux, kernel 6.19.8, Vulkan 1.4. On stock `main` 8c92fe3, three starts: every start logs `its dma-buf not imported (VkResult -2)` (7 lines on a first start, 1 on the next two) and adds exactly one `NVRM: memMap_IMPL: CPU mapping not supported for addressSpace: 0x1` to the kernel log. The pools then import as host pointers and the game reaches its first decoder. So this is not specific to 615.78.08. With #2340's `vk_memory.cpp` hunk applied here, two starts: no `VkResult -2`, no new `memMap_IMPL`, and `vk: guest memory as dma-bufs: no (NVIDIA's driver refuses them: host pointers)`. I have not measured frame times. --- 🤖 Generated with [opencode](https://opencode.ai) using DeepSeek V4.1 Flash.

Commenting is not possible because the repository is archived.