multithreading vulkan backend

Skip to first unread message

Zhuo Wang

Apr 7, 2022, 12:25:16 AMApr 7
to skia-discuss
hi all,

i'm currently investegating the possibility to multithread the vulkan backend of skia to shorter the flush time.

i found that skia vulkan backend is already using secondary command buffer, which has the potential to record OpChains into different secondary command buffers with multiple threads and submmit them to the primary command buffer.

when i doing this, i found lots of the class seems to be thread unsafe, like FlushState, GrVkGPU, ResourceProvider etc, and those class are used in the prepare and excute stages of each Op.

so i'm wondering:
1. was skia vulkan backend designed to be serialized from the very begining?
2. does skia developer team have the plan to make it multi-threaded in the future?
3. do you think it would be huge amount of work to make it happen? one needs to totally re-design the backend and do the implemention, or just modify some parts would be enough? 

any comments/advices are welcomed. thanks in advance.

Greg Daniel

Apr 7, 2022, 9:12:37 AMApr 7
to skia-discuss
The current GPU backend is not thread safe and it would take a lot of work to make it thread safe. However, we are in the middle of creating a new GPU backend from scratch. This backend will be thread safe and support recording multithreading of recording commands.

You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Zhuo Wang

Apr 8, 2022, 2:44:31 AMApr 8
to skia-discuss
hi Daniel, thanks for your reply.

it's good to know that your team has already begun to implement the new backend. is the ongoing code public available? when would the new backend be initially released?

Sam Hu

Apr 8, 2022, 3:26:48 AMApr 8
to skia-discuss
hi, there.
I wonder, do u guys actually have some scenario for 2D that can benefit from such multithreading backend ? or it is just a research direction. because in my experience, the gpu command recording is never the bottleneck.

Reply all
Reply to author
0 new messages