I was curious about how the new vulkan-based GSK renderer that shipped with gnome 46 worked so I took a peek using renderdoc. Here is a breakdown animation of each draw call (highlighted with the wireframe overlay):
@nical GSK has always been and still is so inefficient it just hurts to look at in RenderDoc; it's especially noticeable on mobile. Not complaining - it's doing well given the available resources - but if only some company actually invested dev hours into its performance it could do real wonders and make a huge difference.
@nical GPU. Heavy shaders, lots of overdraw, cache and tile unfriendliness, jumping between pipelines back and forth... plenty of low hanging fruits (at least purely from the GPU perspective).
It used to spend the vast majority of frame time rendering a window shadow across the whole surface that was then promptly almost entirely obscured by the window itself 😁 It was particularly bad on phones, but could even be felt on Intel iGPUs with 4K screens.
@dos Makes sense. A bit of draw call batching and segmenting large primitives to avoid, say, evaluating the corners of rounded rectangles over the entire area would go a long way!
@dos I can easily imagine how the high draw call count would hurt a typical mobile device with OpenGL (hopefully less so with vulkan). Do you know whether the performance issues in GSK tend to be on the CPU or GPU side?