Most Significant Graphics Technology for 2005
- Thread starter rwolf
- Start date
Simon F said:You see they're going to be quantum theory based. All games in the near future will send all objects through the pipeline rotated and translated to all possible positions. The pixel shader then will make all rendered pixels belonging to an incorrect position fully transparent. This thus eliminates the need for vertex shaders._xxx_ said:hovz said:
???
QED.
It's a shame when such witty sarcasm gets overlooked
Isn't that load removed with a deferred renderer?
Don't hit me.
Don't hit me.
I don’t think the NV40 has better per/clock performance over the R420. If we look at 3Dmark2005 … techreport …
6800GT …4669
X800pro …4631
Fill rate …
X800pro … 12 x 475 = 5700
6800GT … 16 x 350 = 5600
… … they are very close. The 3Dmark2005 scores (good raw performance metric) for the GT and Pro are almost identical. The GT has faster memory 1000 vs 900 for the Pro which probably gives it a bigger advantage than the Pro’s slight filtrate advantage -- but the per-pipeline-per-clock performance is close between the NV400 and R420. The NV40 is running DST shadows so it is actually running a different code path than the R420. The 6800GT 3Dmark2005 score drops ~ 10% when it doesn’t use DST, so the X800pro would actually easily outrun the 6800GT in 3Dmark2005 with the same workload. This suggests the X800 has faster per-pipeline-per-clock performance than the 6800 in DX9. The 6800 looks faster in OGL (based on game benchmarks). Of course this assumes the driver/compilers are optimized about the same -- but that is another discussion altogether.
The problem with the X800 XT PE higher clock rates is that if you keep memory bandwidth the same and clock only the GPU faster, the GPU becomes less efficient per/clock because the GPU sees less bandwidth/clock.
6800GT …4669
X800pro …4631
Fill rate …
X800pro … 12 x 475 = 5700
6800GT … 16 x 350 = 5600
… … they are very close. The 3Dmark2005 scores (good raw performance metric) for the GT and Pro are almost identical. The GT has faster memory 1000 vs 900 for the Pro which probably gives it a bigger advantage than the Pro’s slight filtrate advantage -- but the per-pipeline-per-clock performance is close between the NV400 and R420. The NV40 is running DST shadows so it is actually running a different code path than the R420. The 6800GT 3Dmark2005 score drops ~ 10% when it doesn’t use DST, so the X800pro would actually easily outrun the 6800GT in 3Dmark2005 with the same workload. This suggests the X800 has faster per-pipeline-per-clock performance than the 6800 in DX9. The 6800 looks faster in OGL (based on game benchmarks). Of course this assumes the driver/compilers are optimized about the same -- but that is another discussion altogether.
The problem with the X800 XT PE higher clock rates is that if you keep memory bandwidth the same and clock only the GPU faster, the GPU becomes less efficient per/clock because the GPU sees less bandwidth/clock.
Blastman said:
3dmark05 is very sensitive to vertex performance. Having a great vertex performance is going to make a dramatic impact on 3dmark05, Paticularly Game test 2 which is the most sensitive to it. I did a test with my Geforce 6800GT and disabled vertex engines to show the effect of vertex power in 3dmark05.
While not limited by vertex, Its definately sensitive to the effects of vertex processing. Given the sensitivity its highly plausable the x800 series can make up for any deficiency(Compared to the Nv4x, The r420 is not slow at pixel shaders by any means, Just clock for clock basis here) they might have in pixel capabilities. I think what people are saying, Clock for Clock, FillRate per Fillrate, Nvidia is quite a bit more efficient currently at pixel processing.
Inane_Dork said:Isn't that load removed with a deferred renderer?
Don't hit me.
Nope, deferred rendering just defers pixel shading to later. Still requires at least the same amount of vertex work.
I.e. You need to store positions and normals in a G-Buffer, so you have to transform/skin etc. them into that buffer.
a guy that invents 100% HSR algorithm that works before Transform, is going to be A) a very rich and famous or B) very rich, but not famous (someone buys the idea and puts it on ice, because it would destroy their business.) or C) dies quietly in poverty. (no one listened to him, or he was coming from conditions that won't allow him to develop the idea further.)
anything is possible... as well as nothing in this particular case.
anything is possible... as well as nothing in this particular case.
Are you arguing about the amount of vertices or the use of shaders? Besides, 3DMark05 is vertex intensive simply because of the sheer number of vertices; technically one could argue that it's also vertex shader intensive too because all vertex processing is done via shaders.hovz said:
Anyway, don't you read our reviews or keep up with discussions? Look at Wavey's X800 preview - particularly the Splinter Cell testing - and take a look at this thread.
I was... kidding. Sorry.DeanoC said:
I guess I should have made it more obvious.
Neeyik said:
that splinter cell graph doesnt necessarily mean vertex limited. the pro has the same number of vertex shaders as an xt, and only 25 mhz lower clocks. yet its noticeably slower. where as the 850pe v the 800pe has a similar clock increase and is barely faster. if anything id say its memory bandwidth limited at low res, and more pixel limited at high res.
Doesn't 3dmark do shadow volume extrusion via vertex shaders? This is certainly something that won't be done via VS in the future. I believe the future lies in programmable tesselation units, in which case, vertex shading is a subset. Some architectures will just make the tesselator unit general purpose enough to do both, others may keep the tesselate/vertex shade dichotomy. For example, on CELL-style architectures, the CPU may just do everything and Nvidia may just leave transformation out of the GPU. Or, it could keep a pared-down transform unit, but wouldn't need a complex VS3.0 one.
DemoCoder said:
tell me if I am wrong, but I remember seeing something on DirectX Next that it would still see tesselators and vertex shaders as different steps on API level. (Geometry Shader -> Vertex Shader -> Rasterizer / Pixel Shader)
But of course, unified shaders are coming and it would be more logical combine tesselators and vertex shaders in HW level than VS and PS. GV and VS seem to be closer to each other on data types and calculated data than PS and VS.
DemoCoder said:
That's 3dmark03.
3dmark05 uses shadow buffers instead of shadow volumes.
And I suspect that the shadow buffer rendering is what's vertex limited.
That's why depends on both VS speed and PS speed.
Unlike CPU vs GPU there's not enough buffering between VS and PS to even that out.
So a game can be both limited by vertex and pixel shader performance.
