GPU-accelerated path rendering

[Mark Kilgard]

www.opengl.org,

Normally 3D rendering and high-quality, path-based 2D rendering are distinct forms of rendering that cannot easily be mixed. Moreover while the GPU excels at 3D rendering, conventional path rendering systems for PDF, Flash, SVG, HTML 5 Canvas, TrueType, etc. have depended on the CPU for 2D path rendering.

The latest NVIDIA drivers support a new OpenGL extension called NV_path_rendering that changes this. Now CUDA-capable NVIDIA GPUs can fully accelerate path rendering. Check out:

http://developer.nvidia.com/nv-path-rendering

Get a release 275.xx NVIDIA driver (or better yet, the 280.19 beta driver) and try out the demos. Get drivers from (or search for your OS):

http://www.nvidia.com/object/winxp-2...ta-driver.html
http://www.nvidia.com/object/winxp-2...ta-driver.html

NV_path_rendering is supported for Windows XP, Vista, Windows 7, Linux, FreeBSD, and Solaris in both 32-bit and 64-bit OS flavors.

NV_path_rendering allows path objects containing line segments, quadratic and cubic Bezier segments, and partial elliptical arcs to be transformed then filled or stroked entirely on the GPU. The stroking includes all the standard embellishments such as end caps, join styles, and dashing. Unlike conventional path rendering systems where shading is generally limited to solid color, linear gradients, radial gradients, and simple 2D texturing, NV_path_rendering allows arbitrary OpenGL per-fragment shading to be applied to filled or stroked path. So you can use fixed-function, Cg, GLSL, or assembly shaders.

Rendering glyphs from fonts is a first-class feature in all path rendering systems. NV_path_rendering is no different and allows you to create path objects from either standard driver-supported outline fonts (same on every platform where NV_path_rendering is supported) or use system fonts. Instanced path rendering makes it easy to draw sequences of characters, including kerned spacing. There's support for rendering text directly from Unicode UTF-8 or UTF-16 strings. This makes high-quality font rendering truly portable across operating systems; the same NV_path_rendering font rendering code for Windows just works on the non-Windows platforms.

For a good overview of what NV_path_rendering supports, see the "An Introduction to NV_path_rendering" presentation:

http://developer.download.nvidia.com..._rendering.pdf

For programmers, the "Getting Started with NV_path_rendering" tutorial shows how easy it is to GPU-accelerate path rendering. See:

http://developer.download.nvidia.com..._rendering.pdf

The NVprSDK includes the source code for the nvpr_whitepaper example discussed in the "Getting Started" tutorial. Get NVprSDK from:

http://developer.download.nvidia.com...es/NVprSDK.zip

There's also a nvpr_hello_world example included in the NVprSDK that really renders "Hello world!" in OpenGL with the first-class text support. The text uses a system-supported sans-serif font, includes stroked outlining for emphasis or offsetting the text from background imagery, underlining, kerned spacing, and the text is drawn the a green-to-blue vertical gradient.

NV_path_rendering mixes seamlessly with the rest of OpenGL. So you can mix path rendering with depth-tested 3D rendering in projective views. Read the "Mixing Path Rendering and 3D" tutorial to learn how to do this. This tutorial also shows how to apply arbitrary OpenGL fragment shading to paths. This isn't something you can do with conventional path rendering systems. See:

http://developer.download.nvidia.com...ing_and_3D.pdf

Making path rendering a first-class rendering mode in OpenGL means you can use OpenGL clip planes, scissoring, depth testing, stencil testing, transformations, color/texture coordinate/fog generation, stippling, fragment shading, blending, and multisampling while rendering paths. Path rendering and 3D really are on equal terms now and fully GPU-accelerated. The same matrix transformations, textures, and fragment shaders you use for 3D rendering can be used as-is with path rendering.

Definitely check out the nvpr_tiger3d and nvpr_shaders examples.

If you want to just try out the 14 examples in the NVprSDK, I recommend running the pre-compiled examples found in the NVprDEMOs distribution:

http://developer.download.nvidia.com.../NVprDEMOs.zip

The most interesting demo is the nvpr_svg example. It shows how GPU-accelerated path rendering with NV_path_rendering compares to other path rendering systems in both performance and quality. You can compare NV_path_rendering to Cairo, Skia, Qt, Direct2D (requires Vista and Windows 7), and the OpenVG reference implementation. You'll find NV_path_rendering is generally much faster.

For non-Windows users on Linux, FreeBSD, or Solaris, you can run these same demos but you'll have to be a bit more ambitious and build the demos from the NVprSDK but you can play with the same demos.

Most CPU-based path rendering systems have to make approximations in the interest of speed. They often approximate curved path boundaries with line segments, particularly for stroking. They typically conflate opacity computations with transparency. They take short cuts filtering color ramps for gradients or image texturing. All these simplifications and approximations diminish the overall path rendering quality.

However CUDA-capable GPUs are massively parallel architectures that make direct rendering of paths without such approximations. This leads to better overall rendering quality while at much faster rendering rates.

More questions? Try the FAQ:

http://developer.download.nvidia.com...dering_FAQ.pdf

I hope this helps.

- Mark

[Aleksandar]

Thank you very much!

This extension is great. I really appreciate the documentation provided with the extension and the promptness of the publication.

[mfort]

It looks really good. Seems like answer to Microsoft's Direct2D.

[glfreak]

Great!! Thank you NVIDIA for this great extension. Keep leading the GPU industry. Now we got text rendering supported by the hardware, one I suggested in a different way but some ppl did not really like it.

[aronsatie]

I hope this helps.

- Mark

Are you kidding???

There are a few things I have been praying for for quite some time. This was on the top of my list.

[Alfonse Reinheart]

So NVIDIA decided to implement OpenVG in hardware. Only instead of implementing a cross-platform, open specification, they decided to implement an NVIDIA-only proprietary platform that will never be available outside of NVIDIA's platforms and will never be a part of OpenGL itself.

This is all very nice functionality to play around with, but this feels a lot like vendor lock-in to me. This isn't something like bindless rendering, where you can easily render one way or the other for different platforms. There's no simple switch for rendering the normal way and the NV_path way. If you're using this stuff, you're not going to re-implement an alternative rendering mechanism for it. Which means if you use it, you live in NVIDIA's world now, relying explicitly on their APIs for your application to function.

And while that's fine for some people, that's far from universal. Not everyone wants to live there, and not everyone can even if they wanted to. Isn't OpenGL's greatest (perhaps only) strength the fact that it is cross-platform? That you can run just fine on Windows, Linux, MacOSX? That you can run on NVIDIA or AMD equally (bugs aside)?

So while I can understand the "this is great to have!" sentiment from a features perspective, I can't say I like the encouragement for developers to bind themselves tightly to NVIDIA hardware.

This is fine functionality and all, but why wasn't it part of an OpenVG implementation instead of something proprietary?

[glfreak]

This is fine functionality and all, but why wasn't it part of an OpenVG implementation instead of something proprietary?

Where's OpenVG32.dll or whatever it's called under whatever platform? How can I use it? Any PC implementation?

How would it coexist/work with OpenGL window?

This extension will soon be adopted by the ARB, probably will become EXT...

In short words, it's a First Class Extension that will make OpenGL a more kick-ass API!!!

[Gedolo]

I would like to have 3d paths please.

That the paths themselves can be in 3 dimensions.
Would be nice to be able to build scenes with them.

Also regarding OpenVG.
As api it actually wasn't very good.

Having a format independent api will allow much more flexibility.
This will be much more usable for all kinds of formats.

Also making the font stuff codepoint independent for fonts would also be a nice flexibility. I'm not saying the current stuff with UTF-8 should go but that there should be room for future encoding systems. Independent of the api.

I don't see groups of paths anywhere mentioned in the presentation. Instancing is great, please keep that.

Groups (especially if combined with instancing) would really be handy, especially when using fonts and doing text.



Reading through An_Introduction_to_NV_path_rendering.pdf

Please make a single, general and uniform circular/elliptical arc primitive.
I don't think using path format is a great idea.
We already have OpenVG.
And these formats continue to evolve. You just need to have universal usable building blocks that can be used to make everything from. Please separate the api from formats. You can always introduce formats in an SDK or software library.

About slide 17.
It would be nice to change the end caps to round or square and have a parameter that says what the length of the caps should be. And it should be possible to use another path or group as caps.

I would like to be able to specify that a path borders should end in a path or group used as caps but should not come back out.

It seems like the join styles can also be shortened to two, with a parameter that tells how far to cut the rest of the sharp tip off.

All these 'example' dash styles seem like a can of worms.
(When is it enough, should there be more added? Yes/No It never stops. There is always going to be another style.)

Being able to intelligently define a pattern and use that along a path should be able to be used to recreate all these styles.

Don't make too much different path functions that can be done with a smaller amount of more universal ways of doing things.

This is an api for making paths. It's not a data format but a bunch of functions. It needs to capture essence of and the path primitive. It needs to be format independent.
The decorations of paths need to be constructed from the primitives, not be them.

OpenGL used to have a fixed function pipeline but it didn't worked out. Please don't make the same mistake.

You can always introduce standard styles with an SDK that adds these more constructed stuff. Just as there are libraries for OpenGL.

This stuff is great but it needs to be improved.

There are a lot of generalizations possible that can reduce the amount of primitive functions while making them more flexible and powerful.

[Gedolo]

After reading some more.
Some additional things come to mind while reading
An_Introduction_to_NV_path_rendering.pdf



At slide 12.
It would be better to have functions that allow to change the origin to a relative origin and back again instead of having a dozen of functions with relative origin.
Being able to name the origins would be nice too.



At slide 13

Instead of cramming everything in GL_NV_path_rendering

Please do an extension for the formats that includes the version in the title. The version number of a data format is important and necessary. It really is. The underscore between the two numbers in the svg and ps extension name is also important. It allows to make a difference between what is the major and what is the minor number.

Add two new extensions and keep most non-specific functions separate from file formats:

GL_NV_format_SVG_1_1_
This way everything that has to do with svg specifically can be put in here.

(The last underscore allows to make a difference between the version of the format implemented and the version of the extension.)

If there is a underscore behind it, it's a version number of the format. If a number is the last thing in an extension, it's the extension number. Being able to do this allows for changing specifications without breaking things. Supporting several file formats and versions of the same file format alongside each other without interfering with each other and extension/OpenGL api specification evolution/numbering.

GL_NV_format_PS_?_?_
This way everything that has to do with postscript specifically can be put in here.



At slide 35
I would like to see more general intelligence placing of stuff instead of just glyphs.
(Kerning <> Using bounding boxes when wanting to place a series of objects next to each other without overlapping. With relative start location and direction. Allowing objects to have a separate box with user definable origin and size, origin relative to the glyph, as a bounding box.)

It doesn't have to be text or glyphs. Just paths and other things e.g. textures or stuff from the 3d rendering pipeline.

Options in the clone dialogue of Inkscape come to mind.



slide 54
Being able to fill a box or the inside of a closed path with figures would be nice too. Something like the flowing text in Inkscape but more general.

Able to specify the relative begin and direction of flow.
e.g. origin: left, bottom
direction: right,up

englis: origin: left, top direction: right, down
chinese: origin: left, top direction: down, right

This would start in the left bottom corner. It would place the first thing, then place the next thing right of the first thing when the 'row' is full. It will go one 'row' up and start from there.

Lots of stuff done with fonts also has a general equivalent.
I would like to be able to use that instead of this specific subset where the restriction (that the path is a glyph) has almost no difference to any other path or group of paths.



Maybe it would be nice to move all font stuff to a separate extension? Which then could contain all the stuff about fonts.
Something like:
GL_NV_path_rendering_font

These modularities can make it much easier to develop the different part of the specification. (And getting the specifications promoted or even in core if wanted.)

[Gedolo]

Another discussion about this:

Path rendering - OpenGL.org Discussion and Help Forums