Comment by badlibrarian
2 days ago
Author uses a lot of odd, confusing terminology and brings CPU baggage to the GPU creating the worst of both worlds. Shader hacks and CPU-bound partitioning and choosing the Greek letter alpha to be your accumulator in a graphics article? Oh my.
NV_path_rendering solved this in 2011. https://developer.nvidia.com/nv-path-rendering
It never became a standard but was a compile-time option in Skia for a long time. Skia of course solved this the right way.
> NV_path_rendering solved this in 2011.
By no means is this a solved problem.
NV_path_rendering is an implementation of "stencil then cover" method with a lot of CPU preprocessing.
It's also only available on OpenGL, not on any other graphics API.
The STC method scales very badly with increasing resolutions as it is using a lot of fill rate and memory bandwidth.
It's mostly using GPU fixed function units (rasterizer and stencil test), leaving the "shader cores" practically idle.
There's a lot of room for improvement to get more performance and better GPU utilization.
While the author doesn't seem to be aware of state of the art in the field, vector rendering is absolute NOT a solved problem whether on CPU or GPU.
Vello by Raph Levien seems to be a nice combination of what is required to pull this off on GPUs. https://www.youtube.com/watch?v=_sv8K190Zps
Yeah, I have high hopes for Vello to take off. I could throw away lots of hacks and caching and whatnot if I could do fast vector rendering reliable on the GPU.
I think Rive also does vector rendering on the GPU
https://rive.app/renderer
But it is not really meant (yet?) as a general graphics libary, but just a renderer for the rive design tools.
AFAIK you can use the Rive renderer in your C++ app.
http://github.com/rive-app/rive-runtime
> While the author doesn't seem to be aware of state of the art in the field
The blog post is from 2022, though
You know nothing.
Skia is definitely not a good example at all. Skia started as a CPU renderer, and added GPU rendering later, which heavily relies on caching. Vello, for example, takes a completely different approach compared to Skia.
NV path rendering is a joke. nVidia though that ALL graphics would be rendered on GPU within 2 years after making the presentation, and it took 2 decades and 2D CPU renderers still shine.
I believe Skia's new Graphite architecture is much more similar to Vello
Right. The question is does Skia grows its broad and useful toolkit with an eye toward further GPU optimization? Or does Vello (broadened and perhaps burdened by Rust and the shader-obsessive crowd) grow a broad and useful API?
There's also the issue of just how many billions of line segments you really need to draw every 1/120th of a second at 8K resolution, but I'll leave those discussions to dark-gray Discord forums rendered by Skia in a browser.
5 replies →
So what is the right way that Skia uses? Why is there still discussion on how to do vector graphics on the GPU right if Skia's approach is good enough?
Not being sarcastic, genuinely curious.
The major unsolved problem is real-time high-quality text rendering on GPU. Skia just renders fonts on the CPU with all kinds of hacks ( https://skia.org/docs/dev/design/raster_tragedy/ ). It then renders them as textures.
Ideally, we want to have as much stuff rendered on the GPU as possible. Ideally with support for glyph layout. This is not at all trivial, especially for complex languages like Devanagari.
In the perfect world, we want to be able to create a 3D cube and just have the renderer put the text on one of its facets. And have it rendered perfectly as you rotate the cube.