Rewrite of the graphics and present queue index determination#93
Rewrite of the graphics and present queue index determination#93asuessenbach wants to merge 1 commit intoKhronosGroup:mainfrom
Conversation
|
Lgtm
…On Wed, Jul 9, 2025, 9:14 AM Andreas Süßenbach ***@***.***> wrote:
I think, this code better shows the logic followed here, to determine the
two queue indices.
If it looks good, I can again carry that over to all the other chapters.
------------------------------
You can view, comment on, or merge this pull request online at:
#93
Commit Summary
- a82b3b0
<a82b3b0>
Rewrite of the graphics and present queue index determination
File Changes
(1 file <https://github.com/KhronosGroup/Vulkan-Tutorial/pull/93/files>)
- *M* attachments/05_window_surface.cpp
<https://github.com/KhronosGroup/Vulkan-Tutorial/pull/93/files#diff-3b4cc1c79ce3306e3bf441678cf344831c8be96c809aba4234555865d427b189>
(74)
Patch Links:
- https://github.com/KhronosGroup/Vulkan-Tutorial/pull/93.patch
- https://github.com/KhronosGroup/Vulkan-Tutorial/pull/93.diff
—
Reply to this email directly, view it on GitHub
<#93>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5IAY3YSTPTOSZJGBSJQRL3HU5VBAVCNFSM6AAAAACBESXN6CVHI2DSMVQWIX3LMV43ASLTON2WKOZTGIYTMNBXGI4DSNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Code change looks good, but does the tutorial support different graphics and present queue family indices? If not, what will happen on configurations where both differ? Does the tutorial account for that (e.g. sync)? |
Don't know. I just reformulated what was already there: if there's no queue that supports both graphics and present, determine separate queues. |
|
Any idea on how to resolve the windows build? |
|
I'm trying to figure it out right now. Maybe we need to merge the latest from master? Just a guess, I'm actively looking at it to see if there's a solution for what went wrong. |
|
If you can merge the latest from master, it should hopefully clear up the CI windows build. |
I'd be happy to do so. Do you actually need both of those files? Or could you remove one of them? |
|
Not sure when that got changed. you only need one of them. On platforms that are case sensitive it must match what's called by find_program* In this case find_package (TinyGLTF REQUIRED) So, should nuke tinygltf. I'm making a PR for you right now. |
|
Okay, go ahead and grab the latest, All CI is now working in Main. |
|
Ok, the issue with the But I still can't get a solution out of CMake. Which I could resolve by allowing Authenticated Users to create symbolic links. But I doubt that you should require that from any Tutorial user. Next I have this error: And I don't know how to resolve that. |
|
On windows you have to use the vcpkg toolchain, which feels a bit odd. E.g. I haven't found out how to do that with the cmake-gui. Easiest way is running install_dependencies_windows.bat to install all dependencies via vcpkg and the run cmake at command line with the location where you installed/downloaded vcpkg, e.g.: cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=V:\github\vcpkg\scripts\buildsystems\vcpkg.cmake |
|
Even running Does that tell you anything? |
|
It looks like vcpkg is unhappy about not being able to resolve where a repository lives. This is the first time I've really tried to use vcpkg in a non-toy setting; so, not sure about the best way to solve this. Basically, I know vcpkg is the microsoft blessed method of providing the packagaing service other more "modern" OSes get out of the box ;-) (Yep, I'm more into Linux than Windows). |
|
Ok, pulling and bootstrapping vcpkg again resolved the issue with But I still can't generate a VS solution, something seems to be wrong with KTX: Or is there something with nlohmann_json or tinygltf, which are never found and always fetched again from GitHub.? |
|
I initially had the exact same issue. For whatever reason the build did pick up a wrong version of those libraries I had installed earlier on. Make sure to clean the CMake cache. If that doesn't help, remove any manual installation of those libs (e.g. via the Vulkan SDK) and do clean vcpkg setup to get rid of those errors. cache. |
That didn't help
The only ktx installation I can find is the one in Vulkan-Samples/third_party. Could that be the culprit? |
|
I think we're getting into the fetch_content world of cmake not being helpful; usually it just works great. But every once in a while, things like this happen. It's one of the reasons I'm more of a fan of git submodules when working in projects like this. That should take a bit, you should see ktx, gltf or any other package the package manager vcpkg can't find populate and build in a temporary folder under build. When that step completes, go ahead and open the project and build. usually that makes fetch_content behave. If this proves to be a headache, I might start moving the project to git submodules so everyone has the same thing and maybe only use vcpkg in windows for the simpler, more standard packages. |
In |
3 participants
I think, this code better shows the logic followed here, to determine the two queue indices.
If it looks good, I can again carry that over to all the other chapters.