Slow flush calls

[Leon Scroggins]

Hi!

We're using Ganesh on Vulkan on Linux to draw lines and polygons. Sometimes flush is extremely slow. Any suggestions on how to start debugging?

It's been a while ;)

[Noelle Scobie]

Hi, Leon! :)

Assuming you're the one compiling the copy of Skia in question, https://skia-review.googlesource.com/c/skia/+/1131277 adds an easy way to aggressively trace every API call Skia makes to Vulkan, which may be a helpful start. Also, knowing what the relatively tiny slices at the start and end of that long GrDrawingManager::flush slice are would help guide where else you should add TRACE_EVENT0(...) calls to narrow things down.

Cheers!

-Noelle

--
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 visit https://groups.google.com/d/msgid/skia-discuss/aba404c8-daf1-4252-80d9-365ccabda31cn%40googlegroups.com.

[Aitor Gomila]

Hey!

Out of curiosity, what profiler do you use? I'm looking for one!

[Leon Scroggins]

Thanks! I'm not seeing the same problem right now. I think it was reduced by removing some contention on the GPU.

When I worked on Skia, I typically used Perfetto when working with Skia on Android. But you can also override SkEventTracer to integrate with other systems.

--

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 visit https://groups.google.com/d/msgid/skia-discuss/7b6383b5-d4cf-47de-8ab3-0161beff5d83n%40googlegroups.com.

[Leon Scroggins]

Yes, we are compiling Skia, so I'm able to patch in your CL. (Thanks!)

Now we're looking to use Graphite (Vulkan) and Recorder::snap can be very slow. Below, you can see that one instance taking 37 ms. Most of this time is in the VulkanAMDMemoryAllocator. The Skia_DrawRegion calls seem slow, too - that's a trace in our code, but the green blocks below are all SkCanvas::drawPath. Any suggestions on how to speed up or diagnose either issue?

Regarding the allocator, maybe there is a lot of contention due to the fact that we're recording from several different threads? I'm looking into creating my own VulkanMemoryAllocator subclass, which would make it easier to test/verify that. (And I understand using Skia's VulkanAMDMemoryAllocator is an option that is being phased out, so might as well get started.)

[Greg Daniel]

Yes it is most likely caused by using it from many threads at once. Even though it's thread safe VMA still needs to hold locks for various operations.

Also we've seen evidence that she vulkan drivers can have pretty bad performance when hit with heavy vulkan work from multiple threads at the same time.

To view this discussion visit https://groups.google.com/d/msgid/skia-discuss/CACRH1LBoJMCCxkK6J1ifuuvXYJbKFBPLgzYUbOHS2%2BHUrae%3DMQ%40mail.gmail.com.