Ford vs Chevy?

[Deflection]

I've followed the advancements of gfx accelerators since the Voodoo days. What strikes me the most about the reviews of the new Radeon and what the NV30 future will contain.

Memory Controllers/Pipelines/Pixel Shaders/Vertex Shaders/Memory

They sound more the same than different now. Each side appears to be adapting the strengths of the other sides design.

Ex.
Nvidia does there own "Hyper Z"
ATI does there own "crossbar" memory controller and pipeline.

Granted some of this may be due to DirectX specifications(Vertex and Pixel shaders), but they look they have started merging towards indistinguishable. They both seem to have found a "best path". I guess what I'm saying is the Radeon 9700 looks alot like the latest Geforce with the Directx9 features built in. Many are saying look at the 9700 to see the features of the NV30 the nmaybe add a few percent for manufacturing process.

Is there any reason to be excited about the future of the PC Graphics Industry when it looks like the designs are so close they will have the same features and nearly identical prefomance depending only on gpu/mem speed? Will their paths diverge again significantly?

 

[DemoCoder]

Yes, there is plenty of reason. First of all, Fords and Chevys don't go through 1000x performance improvements over a decade and cost the same or less.


Secondly, the designs may or may not be converging/diverging. We don't know if the NV30 will be an IMR with 256-bit bus, or a tiler with 128-bit bus, or something inbetween. (although if it has a 128-bit FP framebuffer, I would hope for a 256-bit bus. How about a tiler + 256-bit bus?)

Also, the NV30 is most likely going to include a 3rd type of shading unit for doing PER-OBJECT shading. That means you will now be able to do per object operations, per vertex operations, and per pixel operations. The per-object processor could do things like implement geometry compression, displacement mapping, HOS algorithms, shadow algorithms, ray-tracing setup, etc


I see this race heating up, and things getting more interesting, not boring.

 

[Nagorak]

If the NV30 is a tiler I bet we'll see a lot of driver problems at least at release.

 

[Hellbinder]

Also, the NV30 is most likely going to include a 3rd type of shading unit for doing PER-OBJECT shading

Great, just what we need another BS nvidia only feature.. So that all the Nvidia worshiping developers can contiue the path of favrotism.

I cant wait to hear what the various hardware sites say about this... Ati sux this.. Nvidia is god that... Meanwhile any feature like PS 1.4 that any other company goes with is considered a waste of time...

 

[Geeforcer]

]
great, just what we need another BS nvidia only feature.. That all the Nvidia worshiping developers can contiue the path of favrotism.

I cant wait to hear what the various hardare sites say about this... Ati sux this.. Nvidia is god that... Meanwhile any feature like PS 1.4 that any other company goes with is considered a waste of time...

Sigh...

 

[Hellbinder]

sigh...

 

[DemoCoder]

BS feature? How is a per-object processor BS? Do you realize that there is a natural division in the levels of processing in any 3D application and that gradually we have been moving those to the GPU? T&L used to be done on the CPU, now it is done on the GPU. Likewise, tessellation and other per-object computations are currently done by the CPU, but it makes good dense to move many of these to the CPU.

The Stanford Real Time Shading project, of which ATI is a member also, is pushing this architecture. ATI *will* adopt it at some point in the future, it's only a matter of time. It just so happens that NVidia will probably beat them to market by one generation.


The R300 likely has features that go beyond DX9. Are these bullshit as well?


The per-primitive processor is likely to remain unused in all games until DirectX10. I bet more than anything, the PPP will be used by the workstation market, for real-time previews in 3D Studio, Maya, etc, or on renderfarms when doing commercial 3D offline rendering. So it isn't likely to force any developers to make "NVidia only games" for the PPP.

My guess is, this is just more sour grapes by the ATI fanboys. It's always ok for the underdogs to push the boundaries of 3D graphics, go beyond the mundane OpenGL1.4 standard features, or DX9. However, if NVidia does it, it's bullshit!

 

[LeStoffer]

Well said, DemoCoder...

 

[Sharkfood]

My guess is, this is just more sour grapes by the ATI fanboys. It's always ok for the underdogs to push the boundaries of 3D graphics, go beyond the mundane OpenGL1.4 standard features, or DX9. However, if NVidia does it, it's bullshit!

No, more like taking PS1.4, TruForm or other innovations that were simply discarded as BS in the past and putting other advancements into the category as previous examples did by IHV leading brand X.

The door needs to swing both ways regardless of IHV. If something new, neat, innovative- yet proprietary engulfs a particular IHV's product, then the public response shouldn't balance on who the source providing said technology is. Either it's BS or it's neat/innovative... not double check source and then decide.

 

[demalion]

My guess is, this is just more sour grapes by the ATI fanboys. It's always ok for the underdogs to push the boundaries of 3D graphics, go beyond the mundane OpenGL1.4 standard features, or DX9. However, if NVidia does it, it's bullshit!

Why do you have to persist in taking a specific demonstration of ignorance by Hellbinder and extrapolate it into a generic label of "ATi fanboys", and then go on and label people "ATi fanboys" for things that have nothing to do with demonstrating the original example of ignorance? I've been on the receiving end of that "ATi fanboys" monicker from you, but, guess what, I'm not Hellbinder. This is almost as unproductive as Hellbinder's behavior. Note the lots of text I did NOT quote and criticize, btw.

Could you atleast save the generic labels until there is MORE than one person you think fits the label demonstrating the behavior, maybe, dare I hope, more than two or three as well?

Didn't someone make a democrat/republican analogy about this recently?

 

[PSarge]

BS feature? How is a per-object processor BS? Do you realize that there is a natural division in the levels of processing in any 3D application and that gradually we have been moving those to the GPU? T&L used to be done on the CPU, now it is done on the GPU. Likewise, tessellation and other per-object computations are currently done by the CPU, but it makes good dense to move many of these to the CPU.

Ok, Tesselation I can see. The OGL2 guys tend to think it's the one area which needs to be added to OGL2, but hasn't been yet. They're reasoning is because it's still an ongoing area of research. The path to take isn't obvious, but that's by the by....Fact is I can see that going into hardware in the future (or now even - Parhelia)

...but what else would a per-object processor do?

Object Culling - Possibly, but it'll be cheaper to not send the object to the card in the first place, or if you're talking about a display list/vertex arrays already in graphics memory, then graphics cards are already quite good at throwing away unused geometry.

Collision Detection - again possibly, but the actions based on the results of that collision probably need to be driven by the main CPU.

Object LOD - could be done, but it's only a case of changing a pointer to point to a different version of an object based on distance. Not going to give you a huge speed increase to do it in hardware.

The Stanford Real Time Shading project, of which ATI is a member also, is pushing this architecture

Can you point me to where they say this? I'd be interested to see why they say it's a benefit.

The per-primitive processor is likely to remain unused in all games until DirectX10. I bet more than anything, the PPP will be used by the workstation market, for real-time previews in 3D Studio, Maya, etc, or on renderfarms when doing commercial 3D offline rendering.

Most of the "Special Stuff" done by these programs when they render is done at the vertex/fragment processing stage (the two become a bit blurred - things like micropolys). We already moving down that road, and that's gonna be cool. I would say 2->3 more generations and we'll have hardware capable of doing 90% of what these programs do. Just a lot quicker.

The modelling side of these programs is where they really earn their money, and that's not going to change.

The only information you get moving further back up the chain from vertices gets you is connectivity (i.e. how vertices are connected together). That's good for calculating tesselation, and............please feel free to add to this list. I can't think of anything else!

Paul

 

[Kristof]

Can you point me to where they say this? I'd be interested to see why they say it's a benefit.

I'll second that request. Where do they talk about this except some overview slide where they mention the different parts. Do they describe this primitive level and what they expect to be possible using a primitive processor or define primitive language ?

K~

 

[Xmas]

]Great, just what we need another BS nvidia only feature.. So that all the Nvidia worshiping developers can contiue the path of favrotism.

lol, do you think they tell everyone what they're working at so anyone can implement it at the same time?
Just like any other "company X only" feature, it will hardly be used over the next year or two. But that doesn't make it BS. TruForm and PS1.4 aren't BS either. But developers have to decice whether it's economically sound to support it.

 

[RussSchultz]

Actually, it is just like Ford vs. Chevy.

At least here in Texas, the good old boys are so wrapped up in cheering for something that there are actually idiots who have arguments about Ford vs. Chevy. There's bumper stickers of the "Calvin" character (from Calvin and Hobbes) peeing on either a Ford or a Chevy logo.

Just as there are graphic card fanboys, there are automobile fanboys.

(Of course, I'll probably never buy another Mazda or Chevy in my life, since I've had pretty poor experience with quality on both my purchases in life).

 

[CMKRNL]

Truform was a fantastic idea, and this is just taking it to the next level. Not only can you define your own HOS and how it should tessellate, you can also perform your own LOD. This is essentially taking two things that are fixed function in HW right now (PN Triangles on ATI and Depth Adaptive Tessellation on Parhelia) and making them completely programmable.

I don't know about you guys, but my biggest problem is getting data up to the graphics chip. As 3D engines move towards submitting massive amounts of geometry information we run into this issue more often. Once the data is on-board, it absolutely flies but with R300 we're already seeing a 10:1 ratio in on-board bandwidth vs bus bandwidth with AGP 8x. This gap will only grow as core and memory clocks get higher and bus bandwidth lags behind. A PPP suddenly allows you to perform procedural geometry generation which helps harness the incredible performance of these chips without necessarily being bottlenecked by the bus.

 

[DemoCoder]

The stanford project doesn't specifically say "add a PPP", I infer it from their papers. They have divided the graphics pipeline into 4 areas: per scene, per object, per vertex, and per pixel. They have then created a programming language that allows you to datatype portions of your code so that the compiler knows what granularity the code is executed. It's only natural that the "per object" shaders are run on the GPU, otherwise, why put them in the shading language? May as well let the CPU do it and stick with per-vertex as the most granular.

Like CMLRNL said, all a PPP is doing is taking what was once a fixed function unit and making it programmable. The R200/R300/NV20/NV25 already have per-primitive units to do HOS, they're just fixed function.

 

[noko]

DemoCoder,

Could you explain better the advantages of per object rendering. Since there are many more vertexs then objects in a sceen how can per object make a significant difference?

Also will per object rendering make a difference in being able to cull the backfaces etc.. Or will it be easier for a deferred rendering design setup?

Thinking about it, lets say a cannon ball is shot (thinking of SeriousSam of coarse) the cpu has to transfer each vertex point for the ball to move on the screen and this could be done much more efficiently by doing per object rendering. Is that the case? Please explain. Update: sounds like the vertex shader could do the same thing without any cpu involvement, not sure of any significant benefit .

It does sound cool but does per object rendering require it to be coded in the game or can the drivers handle the issue?? Sounds like you must code for it to work meaning the first series of cards will probably not see to much use of this feature. Anyways please expound on PPP please. Thank you .

 

[Basic]

I thought some Finn would jump in and say this, but I'm at least a Nord.

A programmable, vertex generating processor in the gfx chip. That's nothing new, even Pyramid3D had it.

OK, a bit more serious.
I'd say that there's to much unknown variables here to say anything about it. What kind of input does it get? Is it a bunch of data for three vertices that it "expands" to a lot of vertices? Can it store data betwen primitives? Can it look for data in memory (like a displacement map)? Does it get mesh connectivity info? Does it for sure exist?

Does anyone have any info about it, or is this pure guesses?

Don't get me wrong. Regardless of what the answers to my question above are, I'm sure that it can be a feature that clearly isn't BS (just as truform and PS1.4). But before any discussion on what it could do (just on the basis that it's some kind of per-object shader), I think it's reasonable to know 1) that it exist, 2) what its features are more precisely.

If nobody knows the features, then by all means keep discussing what a per object shader could do (given certain features), but I think that discussion is better disconnected from NV30 until we know more.

 

[DemoCoder]

noko,
Vertex shaders operate on one vertex at a time and cannot create or destroy vertices. However, there are many cases when you want to create or destroy vertices: tesselation, LOD, generating shadow volumes, etc

Yes, you can do this on the CPU, but you could do vertex shading on the CPU as well. Hell, you could do TruForm on the CPU. That's not a legitimate argument for not hardware accelerating it. Your primary bottleneck is going to be generating the data with the CPU and pushing it across the AGP bus, which will be much slower than just pushing some high level objects to the PPP and having it feed the vertex shader stages. What's gonna be faster at generating shadow volumes, or tesselation? The CPU, or a dedicated piece of hardware optimized for the task?


Basic,
We don't know anything about it yet. Perhaps the data format it gets is a free form buffer, or a mesh, or just a triangle. However, I would guess that to handle all the various HOS algorithms, it would need pretty flexible input.

 

[Saem]

Object LOD - could be done, but it's only a case of changing a pointer to point to a different version of an object based on distance. Not going to give you a huge speed increase to do it in hardware.

That's if one is using static LOD, what about dynamic geometric LoD?