Vulkan - wrong images used by samplers when using multiple threads [closed]
I'm currently developing graphic engine using Vulkan and I'm stuck on nasty problem with texture samplers when trying to render scene in parallel. Problem is that when I use single thread to do so, every texture is rendered fine but under multiple threads the textures seem to occasionally switch which produces graphic glitches (examples below). I tried many things like very restrictive synchronization, new samplers per texture, new descriptor sets per worker but none of those changed anything and I'm pretty much lost what to do more. Maybe someone have some vague idea what could be a culprit here?
Here is an example when everything works fine in single thread:
And here is example where few textures are different like empty spaces or strange tree
If you would want to check out the code here's repository ( branch: FirstOracle-0.5.5 ):
https://github.com/n1t4chi/FirstStory
Rendering is mostly performed in this class:
https://github.com/n1t4chi/FirstStory/blob/FirstOracle-0.5.5/FirstOracle/FirstOracle-Engine/src/main/java/com/firststory/firstoracle/vulkan/physicaldevice/rendering/VulkanRenderStageWorker.java
To run, Java 12 is necessary with below run configuration:
Module: FirstOracle-Engine
Main class: com.firststory.firstoracle.templates.optimisation.App3D
VM arguments:
-Doptimised=false
--enable-preview
-DRenderingFrameworkClassName=com.firststory.firstoracle.vulkan.VulkanFrameworkProvider
-Dvulkan.threads=[number of threads to render with, 1 for single thread or 2 for multi]
java multithreading vulkan
asked Nov 22 at 23:47
n1t4chi
211
closed as off-topic by Nicol Bolas, talex, Skynet, CozyAzure, EdChum Nov 23 at 9:34
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Nicol Bolas, talex, Skynet, CozyAzure, EdChum
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I'm currently developing graphic engine using Vulkan and I'm stuck on nasty problem with texture samplers when trying to render scene in parallel. Problem is that when I use single thread to do so, every texture is rendered fine but under multiple threads the textures seem to occasionally switch which produces graphic glitches (examples below). I tried many things like very restrictive synchronization, new samplers per texture, new descriptor sets per worker but none of those changed anything and I'm pretty much lost what to do more. Maybe someone have some vague idea what could be a culprit here?
Here is an example when everything works fine in single thread:
And here is example where few textures are different like empty spaces or strange tree
If you would want to check out the code here's repository ( branch: FirstOracle-0.5.5 ):
https://github.com/n1t4chi/FirstStory
Rendering is mostly performed in this class:
https://github.com/n1t4chi/FirstStory/blob/FirstOracle-0.5.5/FirstOracle/FirstOracle-Engine/src/main/java/com/firststory/firstoracle/vulkan/physicaldevice/rendering/VulkanRenderStageWorker.java
To run, Java 12 is necessary with below run configuration:
Module: FirstOracle-Engine
Main class: com.firststory.firstoracle.templates.optimisation.App3D
VM arguments:
-Doptimised=false
--enable-preview
-DRenderingFrameworkClassName=com.firststory.firstoracle.vulkan.VulkanFrameworkProvider
-Dvulkan.threads=[number of threads to render with, 1 for single thread or 2 for multi]
java multithreading vulkan
asked Nov 22 at 23:47
n1t4chi
211
closed as off-topic by Nicol Bolas, talex, Skynet, CozyAzure, EdChum Nov 23 at 9:34
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Nicol Bolas, talex, Skynet, CozyAzure, EdChum
If this question can be reworded to fit the rules in the help center, please edit the question.
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
1
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
1
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43
add a comment |
I'm currently developing graphic engine using Vulkan and I'm stuck on nasty problem with texture samplers when trying to render scene in parallel. Problem is that when I use single thread to do so, every texture is rendered fine but under multiple threads the textures seem to occasionally switch which produces graphic glitches (examples below). I tried many things like very restrictive synchronization, new samplers per texture, new descriptor sets per worker but none of those changed anything and I'm pretty much lost what to do more. Maybe someone have some vague idea what could be a culprit here?
Here is an example when everything works fine in single thread:
And here is example where few textures are different like empty spaces or strange tree
If you would want to check out the code here's repository ( branch: FirstOracle-0.5.5 ):
https://github.com/n1t4chi/FirstStory
Rendering is mostly performed in this class:
https://github.com/n1t4chi/FirstStory/blob/FirstOracle-0.5.5/FirstOracle/FirstOracle-Engine/src/main/java/com/firststory/firstoracle/vulkan/physicaldevice/rendering/VulkanRenderStageWorker.java
To run, Java 12 is necessary with below run configuration:
Module: FirstOracle-Engine
Main class: com.firststory.firstoracle.templates.optimisation.App3D
VM arguments:
-Doptimised=false
--enable-preview
-DRenderingFrameworkClassName=com.firststory.firstoracle.vulkan.VulkanFrameworkProvider
-Dvulkan.threads=[number of threads to render with, 1 for single thread or 2 for multi]
java multithreading vulkan
asked Nov 22 at 23:47
n1t4chi
211
I'm currently developing graphic engine using Vulkan and I'm stuck on nasty problem with texture samplers when trying to render scene in parallel. Problem is that when I use single thread to do so, every texture is rendered fine but under multiple threads the textures seem to occasionally switch which produces graphic glitches (examples below). I tried many things like very restrictive synchronization, new samplers per texture, new descriptor sets per worker but none of those changed anything and I'm pretty much lost what to do more. Maybe someone have some vague idea what could be a culprit here?
Here is an example when everything works fine in single thread:
And here is example where few textures are different like empty spaces or strange tree
If you would want to check out the code here's repository ( branch: FirstOracle-0.5.5 ):
https://github.com/n1t4chi/FirstStory
Rendering is mostly performed in this class:
https://github.com/n1t4chi/FirstStory/blob/FirstOracle-0.5.5/FirstOracle/FirstOracle-Engine/src/main/java/com/firststory/firstoracle/vulkan/physicaldevice/rendering/VulkanRenderStageWorker.java
To run, Java 12 is necessary with below run configuration:
Module: FirstOracle-Engine
Main class: com.firststory.firstoracle.templates.optimisation.App3D
VM arguments:
-Doptimised=false
--enable-preview
-DRenderingFrameworkClassName=com.firststory.firstoracle.vulkan.VulkanFrameworkProvider
-Dvulkan.threads=[number of threads to render with, 1 for single thread or 2 for multi]
java multithreading vulkan
java multithreading vulkan
asked Nov 22 at 23:47
n1t4chi
211
asked Nov 22 at 23:47
n1t4chi
211
asked Nov 22 at 23:47
n1t4chi
211
asked Nov 22 at 23:47
n1t4chi
211
asked Nov 22 at 23:47
n1t4chi
211
211
closed as off-topic by Nicol Bolas, talex, Skynet, CozyAzure, EdChum Nov 23 at 9:34
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Nicol Bolas, talex, Skynet, CozyAzure, EdChum
If this question can be reworded to fit the rules in the help center, please edit the question.
closed as off-topic by Nicol Bolas, talex, Skynet, CozyAzure, EdChum Nov 23 at 9:34
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Nicol Bolas, talex, Skynet, CozyAzure, EdChum
If this question can be reworded to fit the rules in the help center, please edit the question.
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
1
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
1
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43
add a comment |
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
1
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
1
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
1
1
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
1
1
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
What does "restrictive synchronization" mean in Your case? Does these glitches occur even if there are multiple threads, but in fact they are executed one after another? Are descriptor pools shared across threads? How do You submit command buffers to a queue? Are there any errors reported by Validation Layers?
– Ekzuzy
Nov 23 at 9:16
1
Yes that's what I meant, I tried making threads work only one at the time with same result. I also tried creating descriptor pools in same thread they are used but I also did not see any improvement. Primary command buffers are built in worker threads and returned to main thread where they are all submitted in single call. They are also synchronized with semaphores so that primary buffers are executed in order. Validation layers do not report any errors.
– n1t4chi
Nov 23 at 12:58
1
So maybe it is a driver bug? Did You try running You app on a different hardware? Oh, and I see I made a mistake - I meant "command pools" not "descriptor pools". Are command pools shared across threads? Or is there a separate command pool for each thread? (I expect You have a separate pool per thread, but just to be clear - in general You need a separate command pool for each thread; it's not just fancy recommendation, unless You want to perform full synchronization of recording command buffers on Your own).
– Ekzuzy
Nov 23 at 14:35
I checked it on my other PC and it's exactly the same. About command pools:: each thread have their own (multi thread usage is reported by validation layers). I will try to
– n1t4chi
Nov 23 at 20:43