Tessellator / PPP Still "Optional" In WGF2.0

darn... no PPT on my computer. :(

Anyone willing to lay down a brief...summary, please?
 
Looks like they got it from the WinHEC 2004 slide.

But it's unclear to me whether that means the hardware is optional or that the path going through a tesselator is optional.
 
Hello Dave :)

Would you mind explaining PPP for me? Also, when you say tesselator, what do you mean by this? As in this?

Why were these dropped? Are they semi-useless features being dropped or something developers could use to make better looking games and/or make the process easier for them?

Thanks :)
 
I'll give it a shot, albeit I'll be needing corrections afterwards anyway...

PPP = Programmable Primitive Processor

AFAIK it's the part of the pipeline that can cater for both Topology and Tesselation under circumstances:

Topology:

Actually, today’s graphics processors can create new triangles and, in fact, must do so in cases where line or point sprite primitives are used. Most consumer graphics processors are only capable of rasterizing triangles, which means all lines and point sprites must, at some point, be converted to triangles. Since both a line and point sprite will end up turning into two triangles, which can be anywhere from two to six times as many vertices (depending on the indexing method), it’s best if this is done as late as possible. This is beneficial because, at the essence, these are the exact same operations required for shadow volumes. All that’s required is to make this section of the pipeline programmable and a whole set of previously blocked scenarios become possible without relying on the host processor; Microsoft calls this the “Topology Processorâ€, and it should allow shadow volume and fur fin extrusions to be done completely on the graphics processor, along with proper line mitering, point sprite expansion and, apparently, single pass render-to-cubemap.

Logically, the topology processor is separate from the tessellation unit. It is conceivably possible, however, that a properly designed programmable primitive processor could be used for both sets of operations.
Click to expand...

Tesselation:

Higher-order surfaces were first introduced to DirectX in version 8, and at first a lot of hardware supported them (nVidia in the form of RT-Patches, ATI in the form of N-Patches), but they were so limited and such a pain to use that very few developers took any interest in them at all. Consequently, all the major hardware vendors dropped support for higher-order surfaces and all was right in the world; until, that is, DirectX 9 came about with adaptive tessellation and displacement mapping. Higher-order surfaces were still a real pain to use, and were still very limited, but displacement mapping was cool enough to overlook those problems, and several developers started taking interest. Unfortunately, hardware vendors had already dropped support for higher-order surfaces so even those developers that took interest in displacement mapping were forced to abandon it due to a lack of hardware support. To be fair, the initial implementation of displacement mapping was a bit Matrox centric, so it is really of no great surprise that there isn’t too much hardware out there that supports it (even Matrox dropped support). With pixel and vertex shader 3.0 hardware on its way, hopefully things will start to pick back up in the higher-order surface and displacement mapping realm, but there’s still the problem of all current DirectX higher-order surface formulations limitations.

It’d be great if hardware would simply directly support all the common higher-order surface formulations, such as Catmull-Rom, Bezier, and B-Splines, subdivision surfaces, all the conics, and the rational versions of everything. It’d be even better if all of these could be adaptively tessellated. If DirectX supported all of these higher-order surfaces, there wouldn’t be much left in the way to stop them from being used – you could import higher-order surface meshes directly from your favorite digital content creation application without all the problems of the current system. Thankfully, this is exactly what Microsoft is doing for DirectX Next. Combined with displacement mapping, and the new topology processor, and there’s no longer any real reason not to use these features (assuming, of course, that the hardware supports it).
Click to expand...

http://www.beyond3d.com/articles/directxnext/index.php?p=4#top

Now in that graph in the Peddie presentation just replace topology processor with geometry shader and consider the tesselating unit still being (?) optional and the riddle should be a lot clearer.

I figure that IHVs worry about their transistor budgets and set other priorities. Leaving the tesselation part optional means rather to me, that I shouldn't again expect too much in terms of really advanced HOS.

I personally have another question: assuming an architecture has a separate tesselation unit and a geometry shader, can someone at least try to explain how they're going to be placed in a future pipeline with unified shaders (PS/VS)? Simple speculation of possible reasonable scenarios would do.

With a PPP I figured so far two scenarios that could make sense:

1. PPP---VS
2. VS---PPP---VS

Probably a dumb question <shrug>
 
DaveBaumann said:
Peddie PPT Presentation

Not sure how up to date that is.
Click to expand...

Dual, cascaded vertex shaders
Click to expand...

Dave do you know what this is ?
Is this what ATI was refering to having a vertex shader, a Geometry shader and then after it another vertex shader ?

So the pipeline would be :
Vertex Shader->Geometry Shader (optional)->Vertex Shader->Pixel Shader.

That would allow things like transforming a simple quad (so only 4 vertices), tesselating it in the GS and then doing things like Displacement Mapping in the second vertex shader.

It's a shame that GS is optional because I'm sure that means that one of the Big Two won't include it and so it won't be used :(

Edit : oups I should have read the next page of the presentation before posting :oops:

So it seems that the Tesselator is optional but the Geometry Shader is not...
 
JonPeddie.com said:
Slides from Computer Graphics World webcast, July 2004: "Professional Graphics"
Click to expand...

I think that answers some of the questions people have.

Boy, I hadn't visited Jon's site in a long time. Man, their site is looking better. Even better than anything I did for them, but that's not saying much anyway as I don't think I ever claimed to be a web page designer. Updates and administrating was more my thing. LOL

Tommy McClain
 
Well, I was finally able to download the slide (the download kept stopping right before finishing when I attempted at home). Anyway, what seemed interesting to me was that the geometry shader, which was apparently not optional, was set between the vertex shader and the rasterizer.

This would seem to indicate a system whereby the vertex shader deals with higher order surface data directly, and all transformation and texture coordinate generation and whatever else the vertex shader is tasked with doing is done before the surface is divided into its component triangles which are then sent to the rasterizer.
 
Anyone care to speculate, how one could place a GS in a pipeline with unified PS/VS units?

Simply:

GS--->Shader Units?
 
I don't know if it'd be anything special. You'd just make it so that there is an option in the instruction set to allow the output of the combination vertex/pixel shader to enter into the geometry shader, which would then generate data to be sent back to the vertex/pixel shader (though there may also be some other hardwired stuff inbetween, like triangle setup).
 
Chalnoth said:
I don't know if it'd be anything special. You'd just make it so that there is an option in the instruction set to allow the output of the combination vertex/pixel shader to enter into the geometry shader, which would then generate data to be sent back to the vertex/pixel shader (though there may also be some other hardwired stuff inbetween, like triangle setup).
Click to expand...


:?:

Input Assembler
|
|
|
Geometry Shader (or PPP)
|
| <- (reusable stream ouput)
|
Rasterizer
|
|
|
Shader
 
Chalnoth said:
Well, I was finally able to download the slide (the download kept stopping right before finishing when I attempted at home). Anyway, what seemed interesting to me was that the geometry shader, which was apparently not optional, was set between the vertex shader and the rasterizer.

This would seem to indicate a system whereby the vertex shader deals with higher order surface data directly, and all transformation and texture coordinate generation and whatever else the vertex shader is tasked with doing is done before the surface is divided into its component triangles which are then sent to the rasterizer.
Click to expand...
But the tessellation of higher order surfaces is an optional part. Although, judging by the description from the WinHEC slides, It could very well be possible to use the geometry shader for tessellation.
 
So, what negatives are there for not having the Tesselator? What benefit would including this be for games? Would a tesselator automatically alter the Level of Detail at distances? Or what exactly would it do if included?

Also, is this a bit of HW that if it is not required, even if one IHV does include it in HW that it wont be used for the most part (and therefor the transistor budget would be best spent elsewhere)?

The Geometry Shader (PPP) sounds pretty cool though :)
 
Xmas said:
But the tessellation of higher order surfaces is an optional part. Although, judging by the description from the WinHEC slides, It could very well be possible to use the geometry shader for tessellation.
Click to expand...
From what I can tell, the geometry shader could be used as a tessellator, but such an architecture would be incapable of any per-vertex computation afterwards: the only available per-vertex data would be interpolated in the geometry shader.
 
Chalnoth said:
From what I can tell, the geometry shader could be used as a tessellator, but such an architecture would be incapable of any per-vertex computation afterwards: the only available per-vertex data would be interpolated in the geometry shader.
Click to expand...
Just have the geometry shader do the per vertex calculations after it's done it's geometry shading.
 
You must log in or register to reply here.

Similar threads

F
RDNA5 Speculation
Replies
2
Views
1K
Erinyes
E
C
Assassins Creed Shadows
2 3
Replies
53
Views
4K
Jupiter
J
Cyan
Life is Strange: Double Exposure [XBSX|S, PS5, PC] Max Caulfield is back.
Replies
4
Views
1K
Cyan
Cyan
iroboto
‘Grand Theft Auto 6’ Sets Fall 2025 Release as Take-Two Posts $2.9 Billion Quarterly Loss
Replies
0
Views
532
iroboto
iroboto
D
Are modern GPU's really offering a worse level of performance than historic GPU's??
Replies
16
Views
2K
Kaotik
Kaotik
Back
Top