alt Hacker NewsAuthor 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.
Replies
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.
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.
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
> 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.