blade-graphics is still going really strong at idno interactive! (https://idno.se/swap) and while our fork has diverged a little bit I still try to keep up with your fixes :)
Anyway, we now have a pretty heavy compute task that runs before our main rendering. I have setup a pair of resources that the compute and render tasks ping-pong.
The compute task works on resources A, while rendering samples resources B. Next frame the compute works on resoures B while main samples from A and so on.
I hoped the driver would be able to see this and schedule them better, but In blade on vulkan however, this gets encoded as a compute task with a full pipeline stall in the main queue and they always run sequentially and in sync. Even though the renderpass doesn't sample from the result of the compute, it still waits for it to finish.
On Apple M1 and M4, the driver succesfully sees that there is no dependency in the current frame and can thus schedule the compute at the same time as the main fragment rendering.
I don't know if we need any semaphores/MTLSharedEvent with cross-queue intra-frame synchronization (yet 😅), but if we every frame could submit one encoder on the main queue and one encoder on a secondary compute queue, we could still use blade's simple single submit syncpoints from the separate queue submissions to schedule this. I am not very familiar with multiple queues yet though so I really don't know.
I will be experimenting in the next week to see if I can hack together a version on my fork that just has a second Context::submit_async() that (if the device supports more than one queue) will submit on a secondary queue and otherwise just fallback to the main queue. I will measure and come back with the results to see if the driver is able to figure it out.
Just wanted to let you know and if you perhaps see a different approach that could solve our usecase I am all ears, and if you have any design suggestions before I potentially submit a PR.
blade-graphicsis still going really strong at idno interactive! (https://idno.se/swap) and while our fork has diverged a little bit I still try to keep up with your fixes :)Anyway, we now have a pretty heavy compute task that runs before our main rendering. I have setup a pair of resources that the compute and render tasks ping-pong.
The compute task works on resources A, while rendering samples resources B. Next frame the compute works on resoures B while main samples from A and so on.
I hoped the driver would be able to see this and schedule them better, but In blade on vulkan however, this gets encoded as a compute task with a full pipeline stall in the main queue and they always run sequentially and in sync. Even though the renderpass doesn't sample from the result of the compute, it still waits for it to finish.
On Apple M1 and M4, the driver succesfully sees that there is no dependency in the current frame and can thus schedule the compute at the same time as the main fragment rendering.
I don't know if we need any semaphores/
MTLSharedEventwith cross-queue intra-frame synchronization (yet 😅), but if we every frame could submit one encoder on the main queue and one encoder on a secondary compute queue, we could still use blade's simple single submit syncpoints from the separate queue submissions to schedule this. I am not very familiar with multiple queues yet though so I really don't know.I will be experimenting in the next week to see if I can hack together a version on my fork that just has a second
Context::submit_async()that (if the device supports more than one queue) will submit on a secondary queue and otherwise just fallback to the main queue. I will measure and come back with the results to see if the driver is able to figure it out.Just wanted to let you know and if you perhaps see a different approach that could solve our usecase I am all ears, and if you have any design suggestions before I potentially submit a PR.