Comments (14)
This might be a loader bug; it looks a bit similar to KhronosGroup/Vulkan-Loader#33. In that case, if no layer intercepts this entrypoint, the loader stub used to crash. This was later fixed (in KhronosGroup/Vulkan-Loader@4b858b5), but the fix doesn't affect the behavior of vkGetDeviceProcAddr, only the behavior of calling the loader stub. So that's probably what's going on here; in this case I think it's a loader bug - I'd expect both GetInstanceProcAddr and GetDeviceProcAddr to return a valid function pointer when the extension support is advertised and enabled.
from volk.
This shouldn't really happen as far as I know. I'll see if I can reproduce this myself. Can you give more details on the HW/SW that you're getting this on? Vulkan SDK version, GPU, driver version, whether you're using RenderDoc.
from volk.
Details (from memory, not in the office now): Win10 x64, GeForce 1060, SDK 1.1.82(.0?), drivers 398.xx, did not use renderdoc during test but renderdoc and its layer is installed in the system.
It really looks like a loader bug as you described because it works fine if I enable std validation layer.
from volk.
Sorry for the delay; I've confirmed that the repro for this is trivial - just enable VK_EXT_debug_utils without any other extensions. I believe the guess above about this being a loader bug is correct, and I've updated a currently-open issue KhronosGroup/Vulkan-Loader#33; hopefully this can be addressed. I'll keep this issue open for now.
from volk.
Ok, thanks.
from volk.
This is now fixed in the loader; the new SDK published today (1.1.92) contains the loader that doesn't have this problem. The fix landed in PR KhronosGroup/Vulkan-Loader#95
from volk.
I've encountered the issue again. vkCmdBeginDebugUtilsLabelEXT returned by vkGetDeviceProcAddr is null and non-zero if using vkGetInstanceProcAddr on AMD drivers and with Vulkan SDK 1.1.114.0.
I've checked the latest spec and according to section 3.1, Table 2 vkGetDeviceProcAddr should not be used to get function pointers of instance level extensions. Do you think this should be fixed in the library?
A bit more context, that could be interesting. Our codebase loads ext_debug_utils extension using vkGetInstanceProcAddr which returns valid pointers but the problem is that markers inserted with these functions are not visible in RGP. On the other hand vkGetDeviceProcAddr returns non-null pointers when RGP is active and in this case markers work as expected. Unfortunately when RGP is not opened vkGetDeviceProcAddr returns null for marker functions.
Right now it looks like that I have to use vkGetInstanceProcAddr to get ext_debug_utils function pointers and then overwrite them with vkGetDeviceProcAddr results if they are not null.
from volk.
Yeah I think this is correct, function pointers that come from instance-level extensions should be retrieved by GIPA apparently.
from volk.
In fact this appears to have changed in 1.0.69:
- Clarify that flink:vkGetDeviceProcAddr only supports device-level
commands (public issue 655).
KhronosGroup/Vulkan-Docs@ab08f09#diff-57bb29a947a8f7ed267e2e5cbf35045a
from volk.
It's a bit of a mess, there's basically three types of functions:
- device-level (core or provided by device extensions); can be loaded by GDPA or GIPA
- device-level (provided by instance extensions); must be loaded by GIPA
- instance-level (core or provided by instance extensions); must be loaded by GIPA
volk doesn't handle the second group correctly; the caveat is that it's unclear if the functions from the second group should be classified as device functions from the point of view of VolkDeviceTable.
My current train of thought leads me to exclude device-level instance extension-provided functions from VolkDeviceTable since you never need to load them from multiple devices when using explicit mGPU. Technically it's an interface-breaking change, hopefully the debug_utils is the only example here so it's not too bad.
from volk.
Sounds good. I only hope that in my AMD situation it would be possible for them (driver? loader?) to fix marker issue so GDPA call (which is a workaround) won't be needed and it still will be fast.
from volk.
Please let me know if the PR fixes the issue for you; as far as I understand, this makes volk spec-compliant in this area, but I don't have an AMD system to test this on.
from volk.
Sure, I will know tomorrow.
from volk.
Works fine for me both on amd/nvidia (no crashes due to null pointers). As expected the issue with AMD profiler still exists but it's not a volk issue.
from volk.
Related Issues (20)
- Missing extension name definitions? HOT 3
- volk + GLFW = (identifier glfwCreateWindowSurface not found) HOT 4
- Warnings from Volk with higher warnings enabled HOT 1
- mold linker symbol mismatch warning HOT 7
- add InstanceTable? HOT 3
- Compile error with MinGW cross-compiler HOT 2
- Access violation in volkInitialize HOT 2
- Device Table Overflow HOT 2
- question on unloading the dll HOT 4
- Should I be calling `volkFinalize()`? HOT 2
- Tagging for versions since 1.3.270 HOT 1
- Question about adding as submodule HOT 1
- dlopen fails to find Vulkan libraries on macOS HOT 6
- Library naming conflict HOT 2
- 1.3.275.0: missing checking VulkanHeaders and volk.c installation HOT 22
- CMake: Should we install volk.c by default? HOT 2
- volkLoadDevice(device) erases some function pointers HOT 3
- Why is volk.c so big? HOT 5
- does volk work with asan? HOT 2
- Tags for versions >1.3.283.0 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from volk.