Barts & tessellation rate, please explain [Archive]

DarthShader

22-Oct-2010, 20:51

How important (or not so) is tesselation rate factor?
Is the limited "bonus" in tesselation for Barts good enough, or its still DX11 not-done-right from the eyes of developer?
http://images.anandtech.com/graphs/amdradeon6000_102110222210/25174.png

Our second tessellation test is Microsoft’s DirectX 11 Detail Tessellation sample program, which is a much more straightforward test of tessellation performance. Here we’re simply looking at the framerate of the program at different tessellation levels, specifically level 7 (the default level) and level 11 (the maximum level). Here AMD’s tessellation improvements become even more apparent, with the 6870 handily beating the 5870. In fact our results are very close to AMD’s own internal results – at level 7 the 6870 is 43% faster than the 5870, while at level 11 that improvement drops to 29% as the increased level leads to an increasingly large tessellation factor. However this also highlights the fact that AMD’s tessellation performance still collapses at high factors compared to NVIDIA’s GPUs, making it all the more important for AMD to encourage developers to use more reasonable tessellation factors.

So I guess the answer would be: it's important. :)

Btw. Found a HAWX2 benchamrk tested:
http://www.hardware.fr/articles/804-17/dossier-amd-radeon-hd-6870-6850.html

Matches an extreme tess setting, doesn't it? But why tessellate ground so much?

Malo

22-Oct-2010, 21:20

What is the difference between them without Tessellation? Is there any way to decrease the Tessellation in that benchmark?

Davros

22-Oct-2010, 21:58

Matches an extreme tess setting, doesn't it? But why tessellate ground so much?

From Amd

"It has come to our attention that you may have received an early build of a benchmark based on the upcoming Ubisoft title H.A.W.X. 2. I'm sure you are fully aware that the timing of this benchmark is not coincidental and is an attempt by our competitor to negatively influence your reviews of the AMD Radeon™ HD 6800 series products. We suggest you do not use this benchmark at present as it has known issues with its implementation of DirectX® 11 tessellation and does not serve as a useful indicator of performance for the AMD Radeon™ HD 6800 series. A quick comparison of the performance data in H.A.W.X. 2, with tessellation on, and that of other games/benchmarks will demonstrate how unrepresentative H.A.W.X. 2 performance is of real world performance.

AMD has demonstrated to Ubisoft tessellation performance improvements that benefit all GPUs, but the developer has chosen not to implement them in the preview benchmark. For that reason, we are working on a driver-based solution in time for the final release of the game that improves performance without sacrificing image quality. In the meantime we recommend you hold off using the benchmark as it will not provide a useful measure of performance relative to other DirectX® 11 games using tessellation."

Xenus

22-Oct-2010, 22:08

No offense to AMD but that sounds like we are worse in the way they are using Tessellation so we will just force our way in drivers kinda like the whole FP11 vs FP16 thing all over again. We can argue the merits of the way HAWX 2 is doing it vs the way AMD wants it done all day but I don't like driver enhancements like this from either side.

no-X

22-Oct-2010, 22:12

DarthShader

22-Oct-2010, 22:49

From Amd
I read that. I am wondering about the practical aspect though, not technical.

I tried to transalte the page from Damien, worked good enough to read, that adaptive tessellation is apparently not in use. So distant miniature triangles will get processed over and over. Ok, I can see the potential of improving the way those traingles would appear on the screen when we get closer, it would be fluid. How about including a switch in the options, for enabling/disabling adaptive tess?

What is the the big thing, which was worth the marketing/PR comedy? The additional 100 FPS over HD5000, which are discarded by 60Hz LCD? Desperate try...
This is a flight simulator. Simulators are a genre, that probably benefits the most from a multimonitor setups. See the issue now?

Sontin

22-Oct-2010, 23:01

I read that. I am wondering about the practical aspect though, not technical.

I tried to transalte the page from Damien, worked good enough to read, that adaptive tessellation is apparently not in use. So distant miniature triangles will get processed over and over. Ok, I can see the potential of improving the way those traingles would appear on the screen when we get closer, it would be fluid. How about including a switch in the options, for enabling/disabling adaptive tess?

You can download the benchmark from here: http://www.nzone.com/object/nzone_hawx2_downloads.html

Check it out. You will see that ubisoft is using adaptive tessellation.
And then, maybe you find the water demo from nvidia. They implemented a dynamic lod setting. But the problem with the adaptive tessellation is that a morphing world is ridicolous. And with a open terrain like in HAWX you can't do it to aggressive.

3dcgi

23-Oct-2010, 01:41

So, Barts goes to 1/2 tessellated throughput up from 1/3 in Evergreen... :roll:
And how efficient is Nvidia hardware? A 460 has twice the theoretical rate.

I think there is some confusion as to what adaptive tessellation means. It's a very generic term. People seem to think it refers to distance based tessellation, but another layer is view angle based. Parts of objects viewed straight on need less tessellation that silhouettes. I don't know what HAWX 2 is doing, but I hope they've at least implemented distance based adaptive tessellation.

Edit: in another thread Sontin linked a presentation (http://forum.beyond3d.com/showpost.php?p=1485797&postcount=4040)describing the tessellation algorithm.

stevem

23-Oct-2010, 02:36

And how efficient is Nvidia hardware? A 460 has twice the theoretical rate.
It may be the case that only the Quadro variants are capable of theoretical rate.

AlexV

23-Oct-2010, 02:52

It may be the case that only the Quadro variants are capable of theoretical rate.

No.

no-X

23-Oct-2010, 09:29

This is a flight simulator. Simulators are a genre, that probably benefits the most from a multimonitor setups. See the issue now?
Which is pretty poor by nVidia, cause you need 2 GeForce cards for 3 LCDs. If you buy 2 Radeons instead, performance will be sufficient for 3 LCDs. No real advantage for GeForce user, again.

CarstenS

23-Oct-2010, 10:48

Even HD5830 performs around 60 FPS at 1920*1200 +AA4x...

What is the the big thing, which was worth the marketing/PR comedy? The additional 100 FPS over HD5000, which are discarded by 60Hz LCD? Desperate try...

AMD seems to think differently. Or why else would they have issued the cited statement if it didn't seem somehow important to them?

no-X

23-Oct-2010, 11:10

Yes, 60 FPS isn't enough for AMD's marketing department, if the competitor offers 180 FPS. But 60 FPS clearly is sufficient for gaming.

GZ007

23-Oct-2010, 11:21

no-X

23-Oct-2010, 11:32

One limit is rasterisation (16 pixels/triangle for Cypress, 8 pixels/triangle for Fermi), another is shading (2x2 pixels for both). But despite these small triangles waste performance (and won't be likely used in most games because of that), it allows to get Cypress short of geometry power and make Fermi look better.

Tridam

23-Oct-2010, 12:59

I read that. I am wondering about the practical aspect though, not technical.

I tried to transalte the page from Damien, worked good enough to read, that adaptive tessellation is apparently not in use. So distant miniature triangles will get processed over and over. Ok, I can see the potential of improving the way those traingles would appear on the screen when we get closer, it would be fluid. How about including a switch in the options, for enabling/disabling adaptive tess?

This is a flight simulator. Simulators are a genre, that probably benefits the most from a multimonitor setups. See the issue now?

Please note that I didn't write adaptive tessellation wasn't in use. What I did write is that AMD implies that developers didn't implement a proper adaptive algorithm.

There are many things adaptive could refer to : screen-space (as it seems to be the case with HAWX2), distance, visibility....

DarthShader

23-Oct-2010, 14:42

Please note that I didn't write adaptive tessellation wasn't in use. What I did write is that AMD implies that developers didn't implement a proper adaptive algorithm.

There are many things adaptive could refer to : screen-space (as it seems to be the case with HAWX2), distance, visibility....
Google translate has failed on me (suprise, suprise). Sorry for the confusion and thanks for the clarification. :)

3dcgi

23-Oct-2010, 16:11

Isnt the fermi also doing something similar like quad fragment merging for shading.
http://graphics.stanford.edu/papers/fragmerging/shade_sig10.pdf
Wouldnt the paralel rasterization go into vain if u would waste so much time on shading even on fermi cards.:?:
I've seen no indication that any GPU performs quad fragment merging. Parallel rasterization is still useful without it because if triangles are small there will be inefficiency in shading with or without parallel rasterization so you might as well rasterize as fast as possible.

sebbbi

31-Oct-2010, 21:04

or its still DX11 not-done-right from the eyes of developer?
Compute shader support (atomics, local memory, programmable output location, etc) is hands down the most important feature in DirectX 11. It makes many algorithms run much faster than before, and allows us to develop many things that were not possible before. ATI DX11 cards run compute shaders really well (if the shader is vectorized properly). The second most important feature is that the DX11 API supports all DX9, DX10 and DX11 hardware (DX10 only supported DX10 hardware - that really limited it's usability in real commercial game titles).

DX11 is DX10 done right. It is finally usable as the only graphics API in a game (no need to code different DX9 path for old hardware). All the important DX10.1 updates (such as MSAA subsample reads) are mandatory for all DX11 hardware, finally letting us developers to use those features as well.

Tessellation is a nice bonus, but not something that all developers want to use. We experimented with it a lot, but per pixel displacement mapping techniques are both faster and look better compared to vertex based tessellation/displacement. When using per pixel techniques you only process visible pixels. This is really important for solid stable frame rate (as the count of visible pixels remains always constant, the count of visible vertices fluctuates heavily). Our artists didn't like vertex based tessellation at all. It works fine for organic surfaces, but for surfaces that have any sharp details (such as stone tiles, cracks, etc) the adaptive tessellation wobbles a lot (new vertices constantly move over the sudden distance variations of the surface). The only way to prevent this is to make the low mesh so that it includes static edges in the sharp transition points, but for terrain surface that can be decaled by arbitrary oriented materials with arbitrary tiling and blending this is impossible (all our terrain decals have per pixel displacement maps). And for objects like ship containers (corrugated iron) and rooftops (http://www.secretsydney.com.au/userimages/user1001_1147528786.jpg) per vertex displacement looks even worse. Per vertex displacement/tessellation has some uses, but for all the small details, per pixel techniques are superior (in both image quality and performance) and require less artist tweaking and change in content creation toolsets and work models.

sebbbi

31-Oct-2010, 21:24

Even HD5830 performs around 60 FPS at 1920*1200 +AA4x...

What is the the big thing, which was worth the marketing/PR comedy? The additional 100 FPS over HD5000, which are discarded by 60Hz LCD? Desperate try...
This is purely a PR issue. Tessellation was hyped by many consumer oriented advertisements as the key new feature in DX11. It's much easier to sell tessellation (displacement mapping) to consumers buying new graphics cards compared to backwards hardware compatibility or compute shaders (too hard to understand the gains for graphics algorithms).

If HD5830 is able to run the game at 60 fps and is completely tessellation (vertex setup) bound, you should be able to bump up the resolution/antialiasing/aniso considerably without any noticeable loss in
frame rate. Select the same IQ improvements for the Geforce running at 150 fps, and it's frame rate will drop a lot more (as it's not vertex setup bound).

It you program a game that is so badly vertex setup bound on ATI hardware that you cannot reach 60 frames per second, you should balance your engine better. HAWX reaches 60 fps mid range ATI hardware, so everything is fine really, there is nothing wrong in the game. You can even run the game at very high resolution with AA and AF set to max, and still have butter smooth 60 fps (the highest refresh rate most consumer LCD panels support) at mid range last generation card supporting DX11. I'd say they have balanced their tessellation usage very well. Why spend more time optimizing for the ATI tessellator, if the game already runs at solid 60+ fps with a mid range ATI card with everything maxed out (and with a huge resolution)?

This is a flight simulator. Simulators are a genre, that probably benefits the most from a multimonitor setups. See the issue now?
Multimonitor means huge resolutions, and the bigger resolution you have, the more pixels you have to process (with 3 monitors you have 3 x pixels to shade, so you will likely be pixel shader bound instead of vertex setup / tessellation bound). Tessellation is a vertex based technique, not a pixel based technique.

trinibwoy

31-Oct-2010, 21:50

It's not just higher resolution. You also see more of the game world so it's more geometry too.

max-pain

04-Nov-2010, 11:00

The second most important feature is that the DX11 API supports all DX9, DX10 and DX11 hardware (DX10 only supported DX10 hardware - that really limited it's usability in real commercial game titles).

DX11 is DX10 done right. It is finally usable as the only graphics API in a game (no need to code different DX9 path for old hardware). All the important DX10.1 updates (such as MSAA subsample reads) are mandatory for all DX11 hardware, finally letting us developers to use those features as well.

But it doesn't really matter anymore. These days the main problem is XP's marketshare not that there aren't enough DX10+ GPUs.

MfA

04-Nov-2010, 11:33

Our artists didn't like vertex based tessellation at all.
I don't like still being able to count polygons. The nice thing about tesselation is that it brow beats the artists into actually getting out of the low poly mindset. If the programmers created tools to go straight from high detail 3D sculpted/painted models to low poly models with relief textures I really couldn't give a shit ... just as long as I can't count polygons any more.

MDolenc

04-Nov-2010, 12:13

It's not just higher resolution. You also see more of the game world so it's more geometry too.
Strictly speaking this is not the problem. Yes you see more geometry, but at the same time you also see alot more pixels. Your average triangle size won't decrease if you run on 3 monitors.
To actually push into triangle setup limits you need small triangles. Radeon 5870 can setup 850M triangles and plot 32 times as many pixels. Meaning that you need triangles that have an area of less then 32 pixels to make setup a problem, becouse otherwise shader core/rops just won't be able to catch up. Or triangles that can be thrown away before they reach shader core/rops.

CarstenS

04-Nov-2010, 12:25

Yes, 60 FPS isn't enough for AMD's marketing department, if the competitor offers 180 FPS. But 60 FPS clearly is sufficient for gaming.

Hm, maybe that's the reason then for Ubisoft to have declined AMDs offer to help? Because they had an apparentyl good looking implementation, which would not be bottlenecked for real gameplay experience by the tessellation unit on AMDs cards down to Redwood? Cedar might be weaker, but shouldn't suffice to run Hawx 2 in 16x10 with AA in the first place, I guess.

Man from Atlantis

04-Nov-2010, 13:20

6870 pure tessellation performance

http://www.geeks3d.com/20101028/test-asus-eah6870-1gb-review-opengl-performances-part-3/
http://www.geeks3d.com/20101028/test-asus-eah6870-1gb-review-direct3d-performances-part-4/

Jawed

04-Nov-2010, 13:32

HD5870 versus HD5770 shows an amazing difference in those tessellation tests :razz:

Laa-Yosh

06-Nov-2010, 15:47

Rodéric

06-Nov-2010, 16:18

You have got to explain how you can displace without using vertices cause I can't wrap my brain around it. What are you moving if not geometry?

Parallax ?

MfA

06-Nov-2010, 16:53

You have got to explain how you can displace without using vertices cause I can't wrap my brain around it. What are you moving if not geometry?
You displace the intersection points of the per pixel raycasting you are doing in the pixel shader.

Mintmaster

06-Nov-2010, 17:29

Tessellation is a nice bonus, but not something that all developers want to use. We experimented with it a lot, but per pixel displacement mapping techniques are both faster and look better compared to vertex based tessellation/displacement.Per-pixel techniques are definitely not faster/better-looking wherever the base geometry is oblique to the camera.

I'm waiting for people to combine the two techniques. Do low displacement/tessellation on base geometry almost facing the camera, and use per-pixel displacement for all the rest. Parallax mapping is already tapered this way, so now it's time to fill in the missing details with tessellation.
It works fine for organic surfaces, but for surfaces that have any sharp details (such as stone tiles, cracks, etc) the adaptive tessellation wobbles a lot (new vertices constantly move over the sudden distance variations of the surface).Those surfaces are even worse for per-pixel techniques unless you do POM, but that is extremely slow. In other words, I'm not convinced that you're comparing quality at equal performance levels.

Per vertex displacement/tessellation has some uses, but for all the small details, per pixel techniques are superior (in both image quality and performance) and require less artist tweaking and change in content creation toolsets and work models.If decals and small details were the only source of visible polygon edges, you could argue that we don't need tessellation. However, that's far from the case.

MfA

06-Nov-2010, 17:49

There is no real limit what you can do with screen space techniques ... if you use a bounding box to determine maximum possible screen space extent and a lot of pixel shader computation you can get 100% accurate raycasting.

Pete

06-Nov-2010, 18:52

Geeks3D posted what they say is Nvidia's GF 580 demo, Endless City (http://www.geeks3d.com/20101106/test-nvidia-endless-city-gtx-580-dx11-tech-demo/#more-7503): 600 million tri/s, procedurally generated, 500k light sources, SSAO, dynamic lighting. It apparently requires CUDA, so no Radeons tested yet, only a 460 (~15fps) and a 480 (~30fps).

DarthShader

06-Nov-2010, 19:20

600 million tris. :shock: To fill a 25x16 screen with one pixel triangles at 60hz you only need to do 240 million tris per second (while doing other things too, ofc). So either the GTX can run this demo on 200+FPS, or there is a ridiculos amount of triangle spam the end-user won't even see. The wireframe pictures show it - he gargoyle looks amazing, but the distant buildings are getting totally white. The non teselated distant buildings look good enough for me.

Laa-Yosh

06-Nov-2010, 19:48

Parallax mapping techniques can't do anything with object silhouettes and fail at so many things compared to vertex based displacement... which is why I wonder what Sebbi's talking about.

trinibwoy

06-Nov-2010, 20:38

Strictly speaking this is not the problem. Yes you see more geometry, but at the same time you also see alot more pixels. Your average triangle size won't decrease if you run on 3 monitors.
To actually push into triangle setup limits you need small triangles. Radeon 5870 can setup 850M triangles and plot 32 times as many pixels. Meaning that you need triangles that have an area of less then 32 pixels to make setup a problem, becouse otherwise shader core/rops just won't be able to catch up. Or triangles that can be thrown away before they reach shader core/rops.

Agreed that the relative workload doesn't change but is the math really that simple? What about all those back-facing triangles that are culled and don't contribute to any pixels? If you assume about as many back-facing as front-facing triangles then your breaking point becomes 64 pixels per front-facing triangle. Correct me if I'm wrong but z-culling happens after setup so overdraw can potentially increase your geometry workload as well without necessarily creating pixel work.

I wish there was more data on geometry throughput. Damien's numbers are nice but it's not always clear what's happening. GF100's numbers go up with tessellation enabled indicating that the non-tessellated test is using triangles that are too large to fully take advantage of Fermi's rasterization throughput. GF104 on the other hand has lower throughput with tessellation enabled - no idea why there would be a discrepancy between the two. With Cypress we have the 1/3 rate during tessellation mucking up those numbers as well but in the non-tessellated case it hits ~99% throughput so the triangle sizing in that test must be just right.

Does anyone know the average size in pixels of a triangle in today's games?

MfA

11-Nov-2010, 16:59

Those surfaces are even worse for per-pixel techniques unless you do POM
Don't all the engines which do parallax mapping now use multi-step methods?

MDolenc

11-Nov-2010, 19:55

Agreed that the relative workload doesn't change but is the math really that simple? What about all those back-facing triangles that are culled and don't contribute to any pixels? If you assume about as many back-facing as front-facing triangles then your breaking point becomes 64 pixels per front-facing triangle. Correct me if I'm wrong but z-culling happens after setup so overdraw can potentially increase your geometry workload as well without necessarily creating pixel work.
That's true in a nutshell. However 64 pixel triangle already has quite nice potential to castrate your shading power. Radeons have a 64 pixel wavefront (8x8 gird) and a 64 pixel triangle has to be spread over at least two wavefronts and wasting at least 1/2 the shading power. So rendering smaller triangles might not necessarily be limited by triangle setup anyway, but by other architecture limitations...

I wish there was more data on geometry throughput. Damien's numbers are nice but it's not always clear what's happening. GF100's numbers go up with tessellation enabled indicating that the non-tessellated test is using triangles that are too large to fully take advantage of Fermi's rasterization throughput. GF104 on the other hand has lower throughput with tessellation enabled - no idea why there would be a discrepancy between the two. With Cypress we have the 1/3 rate during tessellation mucking up those numbers as well but in the non-tessellated case it hits ~99% throughput so the triangle sizing in that test must be just right.
This has been mentioned both on Damien's site and here on Beyond3D review. GeForce variant of Fermi is locked to 1 tri/clock rasterization, you need to get a Quadro board to reach full speed. It will still go full speed with tesellation or when culling. GF104 has 1/2 the geometry power of GF100 and is obviously slower then it's big brother.
Cypress/Barts seem to be limited by the number of UV pairs their tessellator is able to output or push through to rasterizer.

Mintmaster

13-Nov-2010, 16:40

Don't all the engines which do parallax mapping now use multi-step methods?I don't think so. There's a lot of artifacts with POM unless you do a lot of steps, in which case performance falls off a cliff and you're better off just using more geometry. You can see that in the DX11 example. The warping artifacts of regular PM is much more tolerable.

homerdog

13-Nov-2010, 16:44

*Noob OT question alert* What is the difference between regular PM and parallax occlusion mapping? I know POM can work correctly with shadowmaps but is that the only benefit?

MfA

13-Nov-2010, 17:11

I don't think so. There's a lot of artifacts with POM
Well POM is hardly state of the art ... with a little more computation and a little more data per texel you can skip a whole ton of steps most of the time. Anisotropic Cone Mapping for instance.

PSU-failure

14-Nov-2010, 16:15

Per-pixel techniques are definitely not faster/better-looking wherever the base geometry is oblique to the camera.

I'm waiting for people to combine the two techniques. Do low displacement/tessellation on base geometry almost facing the camera, and use per-pixel displacement for all the rest. Parallax mapping is already tapered this way, so now it's time to fill in the missing details with tessellation.
Those surfaces are even worse for per-pixel techniques unless you do POM, but that is extremely slow. In other words, I'm not convinced that you're comparing quality at equal performance levels.

I think the point was that you rarely need accurate simulation and faster "good-looking" techniques would often be a better option.

No need to simulate each cell of the human body to render something looking good enough to be seen as a human character, even if it's advisable to go beyond 3-years old childs drawings, and there's the artist's job.

sebbbi

19-Nov-2010, 10:35

Those surfaces are even worse for per-pixel techniques unless you do POM, but that is extremely slow. In other words, I'm not convinced that you're comparing quality at equal performance levels.
Simple iterative two step slope parallax mapping requires just one extra fetch compared to the old skool parallax mapping, and looks great. Our engine has it on all surfaces, and runs at 60 fps on Xbox 360. DX11 vertex tessellation + displacement with 16x16 adaptive amplification was considerably slower and missed all the fine terrain details. There is no comparison really.

Parallax mapping techniques can't do anything with object silhouettes and fail at so many things compared to vertex based displacement... which is why I wonder what Sebbi's talking about.
Yes they can. If you use any more recent technique. I suggest you to read the newest GPU Pro article "Quadtree Displacement Mapping with Height Blending". The article also has some really good looking per pixel displaced terrain screenshots at steep angles. And this technique is also developed for Xbox 360, so it should run easily at 100+ fps on PC when applied everywhere.

Even our two step iterative slope parallax can do silhouette edges. You just have to make sure the low mesh contains the whole surface inside it (the displacement is negative) and to add some extra checks in pixel shader to discard the fragments in pixel shader that do not hit the map. We have experimented with this, and it works just fine. In DX11 you can also write correct displaced z-values for deferred lighting (conservative hi-z makes this fast).

Well POM is hardly state of the art ... with a little more computation and a little more data per texel you can skip a whole ton of steps most of the time. Anisotropic Cone Mapping for instance.
Agreed. Anisotropic cone mapping is a really good technique. Really fast and good looking. It also works well with virtual texturing (something that quadtree displacement mapping doens't do that well).

sebbbi

19-Nov-2010, 10:48

QDM white paper on net: http://www.drobot.org/pub/M_Drobot_Programming_Quadtree%20Displacement%20Map ping.pdf

Laa-Yosh

19-Nov-2010, 11:50

MfA

19-Nov-2010, 19:30

As long as we are linking the state of the art in parallax mapping ... Indirection Mapping for Quasi-Conformal Relief Texturing (http://graphics.cs.williams.edu/papers/IndirectionI3D08/) is pretty nice. They also agree with me, 3D editors should provide temporary 2D projections for texture editing and keep texture artists away from UV mapping and actual texels :)

All the present pixel shader raytracing methods have problems with animated models compared to displacement mapping though ... their displacement is normal to the flat polygon, not along the interpolated normal. So what is a nicely curved surface can suddenly get a sharp edge (or worse have gaps or obvious penetrating surfaces) during animation.

sebbbi

20-Nov-2010, 10:48

Wow, this looks very interesting.
Not on par with "proper" high poly stuff at a first glance, seems to have problems where two objects interact in any way (at least based on that sewers screenshot) and it can look silly for ground polygons where characters and objects might seem to float above the surface. But still pretty impressive and a lot better looking than simple normal maps.
That's because they haven't written the proper displaced z-values from the shader to the depth buffer (and their character doesn't even seem to cast a shadow). In DX10/DX9 GPUs writing to z-buffer from the pixel shader slows the performance down a lot (you lose hi-z among other inefficiencies). Fortunately DX11 helps with this. If you write the proper z from the shader to your g-buffer and do deferred lighting, the displaced geometry receives the lighting and shadows correctly and objects do not seem to float above it anymore. Objects also z-clip each other properly when intersecting each other.

QDM looks really good on Xbox 360. But we are comparing DX11 vertex tessellation to per pixel displacement here and Radeon 5870 has almost 10x more raw ALU power than Xenos. For a real comparison, I'd like to see an AAA game utilizing properly DX11 optimized QDM (or relaxed anisotropic cone step mapping) running on high end DX11 hardware (instead of many generations old console hardware). The screenshots would look absolutely stunning. You can't get that kind of detail with vertex based displacement techniques alone (not even on 580). Of course a hybrid vertex+pixel displacement algorithm would speed up the per pixel technique, as it would need to travel less space. I think we will see something like that in the future (but not before we get rid of the current generation consoles).

Laa-Yosh

20-Nov-2010, 13:09

Squilliam

22-Nov-2010, 12:17

Interesting - it seems like this time, when we get the next generation of console hardware, there'll be a lot of research already on how to utilize the extra speed and resources. I don't recall the same level of preparedness with the X360 and the PS3 - so maybe we'll see far better efficiency and more striking graphics from the launch titles this time?

Well you could say the engines are already being made and may already be finished by the time the next generation consoles are released. Im pretty sure that CE3 ought to scale pretty well into the next generation whilst maintaining a toe hold in this. However when considering how early the Xbox 360 and PS3 were and the power leap they exhibited in such a short time in comparison to how late the next generation will likely be, at least 7 years after the Xbox 360, they would be pretty embarrassed not to be ready for it.

sebbbi

22-Nov-2010, 19:04

Well you could say the engines are already being made and may already be finished by the time the next generation consoles are released. Im pretty sure that CE3 ought to scale pretty well into the next generation whilst maintaining a toe hold in this. However when considering how early the Xbox 360 and PS3 were and the power leap they exhibited in such a short time in comparison to how late the next generation will likely be, at least 7 years after the Xbox 360, they would be pretty embarrassed not to be ready for it.
Even the current generation titles look "next gen" when played at silky smooth 60+ minimum fps, 1080p+, 4xMSAA and 8x anisotropic filtering. And with 2x2 higher res texture set. This is already possible with current generation PC hardware (and current games).

On current generation consoles the frame rate is often capped to 30 fps (drops to 25 when something big happens), you have only bilinear filtering (with optimized trilinear on selected objects), 720p (often upscaled from something like 1024x600), half res particles and half res post process effects, no antialiasing (or some hacky 2xAA approximation or in some cases 2xMSAA), 10-10-10 bit MDR rendering (instead of full range 16 bit float HDR) and highly compressed low res texture set...

Next gen consoles will have plenty of good engines at launch. And likely will have 10-20x more processing power compared to current generation consoles (Radeon 5970 already has that). The difference will be stunning (on 1080p displays). I just hope this happens before we get mobile phones that are more powerful than current generation consoles (that's likely going to happen before 2015).

Squilliam

23-Nov-2010, 12:04

Even the current generation titles look "next gen" when played at silky smooth 60+ minimum fps, 1080p+, 4xMSAA and 8x anisotropic filtering. And with 2x2 higher res texture set. This is already possible with current generation PC hardware (and current games).

I guess theres a reason why I migrated to PC gaming again after a relatively long hiatus of 3 years or so.

On current generation consoles the frame rate is often capped to 30 fps (drops to 25 when something big happens), you have only bilinear filtering (with optimized trilinear on selected objects), 720p (often upscaled from something like 1024x600), half res particles and half res post process effects, no antialiasing (or some hacky 2xAA approximation or in some cases 2xMSAA), 10-10-10 bit MDR rendering (instead of full range 16 bit float HDR) and highly compressed low res texture set...

The current generation games look and feel a little fake to be honest. I guess mentally it gets more difficult to suspend disbelief when you've been exposed to the same or similar tricks for so long. It seems more noticeable in motion however, I guess the screen shots are chosen with enough finesse to not expose too much of the trickery. I remember feeling this way and more towards the end of the last generation of consoles. It has taken longer but im sure with another couple of years down the track I will be aching for something which looks truely next generation.

Next gen consoles will have plenty of good engines at launch. And likely will have 10-20x more processing power compared to current generation consoles (Radeon 5970 already has that). The difference will be stunning (on 1080p displays). I just hope this happens before we get mobile phones that are more powerful than current generation consoles (that's likely going to happen before 2015).

Im not 100% sure we'll really get 20* the current generation performance unless you're also talking about efficiency. I don't think we'll get a 6B transistor GPU, at best we'll probably see something that looks a little bit like Barts with a little more efficiency per transistor and used with a lot more effective software targeted at that platform.