NV_path_rendering backend

[memononen]

NV_path_rendering backend

[bengarney]

Is this still well supported? I notice nvidia is now on rev 300+.

-- Ben Garney

On Sun, Feb 16, 2014 at 7:58 AM, Andrew Corrigan
[email protected]:

I would like to propose yet another backend for NanoVG based on the
NV_path_rendering extension [1]. For my own code, I run primarily on NVIDIA
hardware, but still need the portability of NanoVG. Once I have NanoVG
integrated into my code, I would definitely like to give this a shot.

[1] https://developer.nvidia.com/nv-path-rendering

Reply to this email directly or view it on GitHubhttps://github.com//issues/25
.

[andrewcorrigan]

Seems to be. I have run it with the latest NVIDIA drivers on Ubuntu and CentOS. It should support Windows as well. Unfortunately it's not available on Mac.

[andrewcorrigan]

I found some more information. The spec was last updated just this past October [1]. The extension spec also indicates that they have continued to optimize their implementation as recently as driver version 314, and implemented bug fixes as recently as driver version 320.

[1] https://www.opengl.org/registry/specs/NV/path_rendering.txt

[sasmaster]

It's supported by NVidia but it the impl is bad.Fixed pipeline dependent.No vertex shader stage access.

[dougbinks]

I don't think a backend based on NV_path_rendering would help performance in any way over the current GL3.2 version. The rendering is already GPU accelerated, and NanoVG does the complex path operations in nanovg.c so a redesign would be required to benefit from any GPU acceleration of this aspect.

So far the performance investigations I've done on the example found very little CPU time in nanovg.c, though it's possible more complex paths with less pixel coverage might start to show up some more cycles/frame here.

Some further acceleration of the current architecture using OpenGL 4.4 is possible, specifically using GL_ARB_buffer_storage and some of the techniques in http://www.openglsuperbible.com/2013/10/16/the-road-to-one-million-draws/ and http://media.steampowered.com/apps/steamdevdays/slides/beyondporting.pdf.

There's also room in GL3.2 to make a few enhancements to performance, but the big wins have already been made.

[sasmaster]

Second with @dougbinks Maybe OpenGL 4.x features is the way to go.

[andrewcorrigan]

In consideration of everyone's feedback, and the fact that I haven't been able to find the time to work on this over the past few months, I am going to close this issue.

[cmaughan]

Andrew - did you actually start it? Just curious; I might be tempted to have a go at this at some point...

[andrewcorrigan]

I didn't actually start it.

[werame]

It's supported by NVidia but it the impl is bad.Fixed pipeline dependent.No vertex shader stage access.

I guess you've missed glProgramPathFragmentInputGenNV. Chromium was perfectly happy with the latter. It's true that most of the Nvidia examples in their ARB NVpr txt use the fixed pipeline... because it's convenient for easy to understand examples.

If you want to complain that NVpr is using the stencil (which is true)

NVIDIA’s Approach to Path Rendering

• Uses “stencil, then cover” (StC) approach
– Create a path object
– Step 1: “Stencil” the path object into the stencil buffer
• GPU provides fast stenciling of filled or stroked paths
– Step 2: “Cover” the path object and stencil test against its coverage
stenciled by the prior step
• Application can configure arbitrary shading during the step

then (FYI) nanovg actually does the same. And without presently offering the custom shader flexibility at that last step. #57 #402