Revealing The Power of DirectX 11

Since this isn't mesh refinement, I don't think things will uncontrollably smooth out. The shape of a patch depends only on its control points -- it has no default relationship to nearby patches (or triangles or quads), unlike like ATI truform. You can have a really flat patch right neighboring a highly curved one. Of course, you could write a hull shader to do things otherwise

 

As for flat surfaces, you might want to take a look at this,

http://castano.ludicon.com/blog/2009/01/27/real-time-creased-approximate-subdivision-surfaces/

 

Call me cynical, but I really doubt that many games will use tesselation during DX11 lifetime. Current game engines content pipelines and tools (data exporters/importers, converters, cache/hi-z optimizers, vertex format optimizers, strippers, etc, etc) are purely polygon based, and it takes a lot of time and resources to recreate the whole content pipeline to work on curved surfaces instead of polygons. Many commonly used 3d content creation programs have lacking curved surface support, and those programs that support curved surface modelling are not in any way standardized (many different curved surface creation models).

Curved surfaces also have problems with the most common shadowing techniques. Rendering curved surfaces to shadow maps can cause surface acne and incorrect self shadows if the model is not tessellated exactly with the same polygon count in the shadow maps. However when rendering near the light object to shadow map using low tessellation (the object is far away from the scene camera) causes very low polygon shadows. When using stencil shadows this problem is even worse (the shadow mesh must be tessellated also, and edges extracted after tessellation). With both techniques the mesh must be tesselated once per frame for each light, unless there is a way to store the tessellation results in memory and reuse them. This however means that tessellation does not save any GPU bandwidth, and just baking the polygon detail would be just as optimal (GPU memory and bandwidth wise).

Skinning of curved surfaces can also be problematic (depending on the surface type). I am sure all these technical problems will be solved, but it will take some time. But the biggest problem is not technology, it's the artists. Currently most of the computer game artists creating 3d models and texturing 3d models are used to polygon based modelling. It's not an easy task to force all the artists to use tools and techniques they have not used to, just because the technology now supports curved surfaces. The curved surfaces have to be a huge jump ahead in real time graphics outlook before the change will be accepted widely.

Compute shaders are really interesting, and will be widely used. However compute shaders are not a graphics feature, and will not directly improve the image quality of future games. But many graphics rendering support/setup tasks previously calculated on CPU can be ported to compute shaders, and the compute shaders can directly output to graphics memory. This will free up CPU resources and reduce needed data transfers between the CPU and the GPU.

 

I think compute shaders have the potential for interesting graphical effects. The pixel shader in D3D11 can use unordered access views, and so it would be possible to emit structs of pixel data and post-process this data with a compute shader.

I can't wait to experiment with this stuff on hardware.

 

Does Nvidia have compute shaders up and running or have I fallen victim to April Fool's madness?

Last couple videos on this page.

 

If you look on this page:

http://mygdc.gdconf.com/vault/1337

and open the first presentation, you will find some downloads. Download labelled Slide #2 is this:

http://cmpmedia.vo.llnwd.net/o1/vault/gdc09/slides/100_Handout 6.pdf

which reveals something called Compute Shader 4.0/4.1. Yes, that's right, compute shader for D3D10/10.1 GPUs

The limitations listed on slide 25 indicate that 8800GTX is the baseline (768 threads). I wonder if AMD GPUs older than HD4870 can do this. Also I wonder if AMD plans to release a driver supporting this stuff publicly.

Jawed

 

I don't think you've fallen victim to April Fools day in this case.

From what I heard at GDC both IHV's have Compute 4.x shaders, which runs on DX10.x hardware, up and running in drivers.
Compute 5.0 capable drivers wasn't talked much about, but could very well be available indoors for showcases like those videos.

[EDIT]
Didn't see Jawed's nice post with links to the presentations, but a well...
[/EDIT]

 

Interesting, thanks guys. Had no idea there would even be such a thing as Compute 4.x

 

In fact Demirug first brought this to our attention:

http://forum.beyond3d.com/showthread.php?p=1235629#post1235629

and I even posted a slide on the subject a couple of posts below. This latest news about drivers being available for developers to actually play, plus the videos from NVidia, means things have progressed very nicely.

Jawed

 

dx11 compute shaders

 

well thats pretty gosh darn impressive!

 

Looks like the water on first FSX screenshots MS was showing around.

 

Hmpf. That was my idea for a compute shader demo. Guess it was just a too obvious application of it.

 

Heres an idea - Fireworks

 

ROFL.
I'm not sure how the computer shader would help me with fireworks though. Fireworks would be loads of independent particles, so a pixel shader would do the job just as good.

 

I'm not sure wether compute shaders are any good for this, but how would a volcano with lava rivers sound? now that I think of it, I can't remember a single instance in gaming at least, not even demos actually, where there would have been volcano with realistic-ish lavaflows & magma bursts etc

 

Do a full crashing wave

 

How about the shockwave from an atomic blast? Could be rather tricky, that one.

 

Hi all - been quite busy lately and mostly lurk, but thought I'd throw in a couple of links for you all. Bit of a shameless plug for my work unfortunately, but figured it might be of interest nonetheless.

I've been doing a lot of work since the MVP Summit in March on D3D11 Tessellation, all of which is posted in my developer journal. In particular I posted a big diagram and explanation of the new pipeline stages - colour coded with arrows and everything - you can view that here.

Recently I implemented Greg Snook's interlocking tiles for terrain rendering entirely on the GPU - fits the HS/DS almost perfectly. I uploaded 3 videos of it to YouTube:



Solid shaded with integer partitioning
Wireframe with integer partitioning
Wireframe with fractional_odd partitioning

In particular, notice how the two with integer partitioning show very noticeable "popping" whereas the fractional_odd one doesn't. A simple change in the Hull Shader declaration effectively gets me geomorphing with no extra dev effort!

I'm writing all this up as an article that I'll get posted somewhere in the next month or so - I'm still working on all the diagrams and example code.

As an aside, I'm optimistic that D3D11 will be picked up by developers - the only downside is that it won't run on WinXP, but otherwise you've got nothing but upsides. The multi-threading, 10-L-9, 10, 10.1, WARP10 and 11 feature sets should make it a compelling API for developers and provided Win7 gives people reason to leave XP then theres less of a problem writing code for a small target audience!

For tessellation the motivation could be business - artists are now costing much more than technology, and I gather that a lot of artists work "natively" in patches and HOS so allowing the code to express their art the way they create it should speed things up which should bring the overall resource cost of art down. A technological solution to a business problem methinks..

Anyway, back to work for me...

Jack

 

That looks really sweet!

Will everyone end up using "the same" tessellation code? If the modelling tools are pretty much common across the industry is there going to be much variation in tessellation algorithms in games?

It seems "cheap", so apart from hardware-specific gotchas, will there be much need for studios to tweak tessellation algorithms to their engines?

I suppose there are interactiions between tessellation and types of rendering pass, e.g. shadow map generation and the use of silhouette-edge-refinement tessellation.

Jawed