Replies: 2 comments 5 replies
-
|
I haven't worked with several GPU for a few years so there is chance there has been a regression. However, getting a crash in vkCreateSwapchainKHR call is something that is so early in the setup that it's less likely that there is some multi-buffering/threading issue at play, or at least so far. Could you run the ''vsgdeviceselection --list'' example, this is what I see with my system with AMD8700G+Geforce2060. $ vsgdeviceselection --list
vkEnumerateInstanceVersion() 4211023
VK_API_VERSION = 1.4.335.0
physicalDevices.size() = 2
matched ref_ptr<vsg::PhysicalDevice>(vsg::PhysicalDevice 0x75d3467c7f48) NVIDIA GeForce RTX 2060, deviceType = 2, apiVersion = 1.4.312, driverVersion = 68.504.576
QueueFamilyProperties 5
VkQueueFamilyProperties[0] queueFlags = GRAPHICS | COMPUTE | TRANSFER | SPARSE_BINDING, queueCount = 16, timestampValidBits = 64, minImageTransferGranularity = {1, 1, 1}
VkQueueFamilyProperties[1] queueFlags = TRANSFER | SPARSE_BINDING, queueCount = 2, timestampValidBits = 64, minImageTransferGranularity = {1, 1, 1}
VkQueueFamilyProperties[2] queueFlags = COMPUTE | TRANSFER | SPARSE_BINDING, queueCount = 8, timestampValidBits = 64, minImageTransferGranularity = {1, 1, 1}
VkQueueFamilyProperties[3] queueFlags = TRANSFER | SPARSE_BINDING | VIDEO_DECODE, queueCount = 1, timestampValidBits = 32, minImageTransferGranularity = {1, 1, 1}
VkQueueFamilyProperties[4] queueFlags = TRANSFER | SPARSE_BINDING | VIDEO_ENCODE, queueCount = 1, timestampValidBits = 32, minImageTransferGranularity = {1, 1, 1}
matched ref_ptr<vsg::PhysicalDevice>(vsg::PhysicalDevice 0x75d3467c83c0) llvmpipe (LLVM 20.1.2, 256 bits), deviceType = 4, apiVersion = 1.4.318, driverVersion = 25.2.8
QueueFamilyProperties 1
VkQueueFamilyProperties[0] queueFlags = GRAPHICS | COMPUTE | TRANSFER | SPARSE_BINDING, queueCount = 1, timestampValidBits = 64, minImageTransferGranularity = {1, 1, 1} |
Beta Was this translation helpful? Give feedback.
-
|
What platform are you working on? In the vsgmultigpu case it sounds like the driver is allocating on device and then the compositor/window manager/driver is copying to the other devices screens. The vsgmultigpu example may need updated to work more like vsgdeviceselection with querying of available PhysicalDevice and then opening windows on the appropriate screen. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I'm trying to render the same scene from two different views, in two different windows, each in a different monitor connected to a different GPU. I have set up a computer with two identical RTX5070 because I'm exploring the performance possibilities of running multiple screens with multiple GPUs.
So far I have found little success. I tried the multi gpu example, but doesn't seem to work properly on my machine. If I launch it on any of the two screens alone it works fine, but launching the program in both screens with parameters -s 0 -s 1, both windows are created, but the first one is automatically closed before it can render anything, leaving the second window working correctly.
I have also tried to implement this on my own.
In this case, creating 2 windows with different GPUs results in a crash in Swapchain.cpp, line 221:
However, creating 2 windows with the same selectedGPU works perfectly fine.
Finally, in this last sceneario where I create multiple windows with the same GPU, I can drag one of them to a different screen connected to the other GPU and I can immediatly see that this second GPU starts being used, but its memory is almost empty. Am I right to assume this is because the first GPU is doing all the rendering and the second GPU is simply copying the resulting frames?
Thanks in advance!
Edit: I have compiled VSG with VSG_MAX_DEVICES set to 3 and I'm using the master branch.
Beta Was this translation helpful? Give feedback.
All reactions