Google Summer of Code 09 - Shader Engine

[imported_gephi]

Hi all,
I’m the creator of the Gephi project, an open-source network visualization software using JOGL. The project have been accepted as a mentoring organization by Google for the Summer of Code. I think I have an interesting proposal to share here: Shader Engine. You may already know how Google SoC works, basically a student will receive payment for working on mentoring open-source projects.

For interested students, see our forum. You can also suggest ideas, until April 3 however. Thanks.

Here is the short version of the Shader Engine proposal:

This proposal is an experimental work about drawing large networks (i.e. graphs) using GPU Shaders technology to improve performances and scalability. The aim is to create a basic 3D engine using suggested technologies and use it for drawing as many nodes and edges as possible.

Existing Gephi 3D engine is intended to be used with old hardware and so don’t profit from GPU revolution. Basically the engine draw only very basic shapes (sphere or cube for nodes and lines for edges), but a LOT of them. Drawing millions of objects, even if it is the same object is currently far from possible.

Shaders technologies have interesting features for our topic. For instance Geometry Shaders and (Pseudo-)Instancing techniques enhance performance when duplicating objects. Other techniques could be explored to reduce the amount of needed vertices or computing.

We suggest this draft roadmap:

* Getting started with loading and executing vertex and fragment shaders within a JOGL routine in a sample application.
* Try pseudo-instancing techniques for duplicating an existing shape, for instance a sphere.
* If available, use Geometry Shaders to implement an instancing test case.
* Try to create a Shader which will help to reduce sphere mesh size. For instance see if it is possible to create a sphere from only few triangles.
* Experimentation for increasing edge drawing performance using Shaders.
* Propose nice post-processing effects if you like!

---

I’m interested with comments about feasability of this project and so on

[Ilian_Dinev]

JOGL - very nice for this project…
3.1 specs are out, outlining what resources most gpus currently have, the question is only in which way to implement it all.

Spheres become point-sprites, for starters.
Geom shaders aren’t quite performant at synthesizing more geometry than input.
Data can be in buffer-objects and textures.
The fillrate and triangle-setup-rate are the limit.

[imported_pjcozzi]

@Ilian_Dinev

Geom shaders aren’t quite performant at synthesizing more geometry than input.

Agreed, at least on today’s hardware. The NVidia Programming Guide states:

The performance of a GS is inversely proportional to the output size (in scalars) declared in the Geometry Shader, which is the product of the vertex size and the number of vertices (maxvertexcount). This performance degradation however occurs at particular output sizes, and is not smooth.

For example, on a GeForce 8800 GTX a GS that outputs at most 1 to 20 scalars in total would run at peak performance, whereas a GS would run at 50% of peak performance if the total maximum output was declared to be between 27 and 40 scalars.

I’ve used geometry shaders for simple shadow volume extrusion and point sprites. In both cases, my vertex shader rendering path was significantly faster (e.g. in one test case VS was 97 fps and GS as 70 fps).

I imagine this won’t always be the case. For one, GS implementations use less VRAM which should result in less swapping to system memory in memory constrained situations.

Anyways, sounds like a cool project. Is it only focused on maximizing rendering horsepower? Or will it also consider techniques like LOD, culling, and image based rendering?

Patrick