multithreading vulkan backend

[Zhuo Wang]

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]

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 skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/c95b0b7d-0d08-4e57-be94-19818a8f6548n%40googlegroups.com.

[Zhuo Wang]

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]

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.

[Zhuo Wang]

based on my experience, gpu command recording could take about one third to half of the total time budget in a typical senario. the reason for why it takes so much time is that it invovles some driver calls (which needs to switch to kernel state), in addition the driver needs to validate the graphics pipeline state during the recording (which is time-consuming).

btw, any update/news for the new backend?

[Zhuo Wang]

hi, it's been a year :). i'm wondering how's the new GPU backend going? any way to contribute to it?

在2022年4月7日星期四 UTC+8 21:12:37<egda...@google.com> 写道：