NV50 specs???

[malachi1313]

saw this over at warp2search:http://www.warp2search.net/modules.php?name=News&file=article&sid=22099 Cool huh??? :D

[jolle]

yeah just saw it too..
whats the deal with 32 (24 real) pipes?
shouldnt it be 32(16) or 48(24), if its refering to the Zrop Crop thing NV30 and NV40 does..

[Daneel Olivaw]

These specs are doubtful, IMO. Especially the 32 vertex engine bit... 32 up from 6 ? bleh, don't believe it. Also, the clockspeeds on memory are not belivable either, or the yields will be very low... same goes for core. I do believe it will use a smaller process to keep costs down, a few more pipes, improved SLI... but the clockspeeds are gonna stay similar to nv40 I think.

[SH64]

Meh .. the time i saw the 32 vertex engines , i knew its not true .

[bkswaney]

# 375-400 million of transistor on 90-nm process
# 550-600 MHz core
# 1600 MHz 256Mb (Support for upto 512Mb) GDDR3
# Graphics Core 256-bit
# Memory Interface 256-bit
# 32 (24 real) pixels pipelines (on the Ultra model)
# 32 Vertex Shader Engines
# 51.2 GB/sec Bandwidth (GDDR 3)
# Fillrate 12.8 billion texetls /sec.
# Textures per Pixel 32 (maximum in a single redering pass)
# Nvidia's LMA - IV
# DirectX 9.0d UMI-23
# Release date Q3 2005.



:eek: :eek: :eek: :p

[bkswaney]

Here's the 6800U Specs based on 400Mhz core. ;)

----------------

* 0.13 Micron Process Technology
* 256-Bit Graphics Processing Unit
* 256-Bit Memory Interface w/GDDR3 Memory
* Memory Bandwidth - 35.2GB per Second
* Fill Rate - 6.4 Billion Texels per Second
* Vertex Processing - 600 Million Vertices per Second
* Superscalar 16-Pipeline Architecture
* CineFX 3.0 Engine - Shader Model 3.0
* On-Chip Video Processor
* UltraShadow II Technology
* High-Precision Dynamic-Range Technology
* Full-Speed 32-Bit Color Precision
* Intellisample 3.0 Technology
* Full MPEG Support
* Advanced Adaptive De-Interlacing
* Video Scaling and Filtering
* Integrated TV Encoder
* AGP 8X Interface
* PCI Express Support
* Dual 400MHz RAMDACs
* Dual Single-Link DVI Support
* Unified Driver Architecture
* nView Multi-Display Technology
* Digital Vibrance Control 3.0
* DirectX 9.0 and OpenGL 1.5 Support

[Razor1]

Meh .. the time i saw the 32 vertex engines , i knew its not true .


32 vertex engines **** ya know what we can do with that lol, forget raytracing hehe.

Yeah it sounds like BS

[bkswaney]

32 vertex engines **** ya know what we can do with that lol, forget raytracing hehe.

Yeah it sounds like BS

Sounds like the R520 specs. :rofl:

[bkswaney]

And here is the R520's specs. :angel:


-----------------------------


24 "Pipelines"
32 Texture Units
96 Arithmetic Logic Units (ALU)
192 Shader Operations per Cycle
700MHz Core
134.4 Billion Shader Operations per Second (at 700MHz)
256-bit 512MB 1.8GHz GDDR3 Memory
57.6 GB/sec Bandwidth (at 1.8GHz)
300-350 Million Transistors
90nm Manufacturing
Shader Model 3.0
ATI HyperMemory
ATI Multi Rendering Technology (AMR)
Launch: Q2 2005
Performance: Over 3x Radeon X800 XT !!! (for single R520)
16x stochastic FSAA
FP32 blending, texturing
Programmable Primitive Processor/Tesselator
Blank

[malachi1313]

As long as they are available right about the time I get back from Iraq...

[retsam]

DirectX 9.0d UMI-23
what the hell is umi-23 and dx9.0d thought the next version is dx-next/wfg or what ever the hell there calling it now


gee the person who made it up just doesnt know what the hell there talking about ...

[MUYA]

Well one thing is for sure, almost in that the next gen architecture of NV might not be unfied architecture as ATi are pursuing. I do not know if this is what the next DX brings but, I remeber what Kirk said in an interview that he did not think Unified architecture is the way to go about things, whether he speaks for NV;s approach or not ...remains to be seen. ATi are i think pursuing unifed model.

[Zelda_fan]

that would be pretty stupid for nVidia to fight WGF becasue 95% of all games are windows only.

[Vagrant Zero]

WGF doesn't call for a unified architecture. Nvidia can still do their thing. And if a disunified architecture is faster than I'm all for it. Jack of all trades, master of none.

[Subtestube]

NV50 is still apparently a fair ways off... All rumours point to an NV4x variant going up against the R520 - I think it's a little presumptuous to trust ANY kind of specs on an NV50 quite yet. As they'll be marketing to competition, I suspect they'll wait to see what the R520 can actually do before finalising the design specs on the NV50.

As for unified architecture, it's really tough to say at this stage. WGF won't realistically be with us until sometime in 2006, so neither nVidia nor ATi need to stress about it quite yet. They'll also both be in close touch with MS regarding what exactly will be required I imagine.

[Nutty]

32 vertex engines **** ya know what we can do with that lol, forget raytracing hehe.

What ?

what the hell is umi-23 and dx9.0d thought the next version is dx-next/wfg or what ever the hell there calling it now


gee the person who made it up just doesnt know what the hell there talking about ...

No, the next version of DX is gonna be dx9.0d AFAIK. Or maybe its you that just doesn't know ? ;)

Maybe the vertex shaders are gonna be unifed with the pixel shader units? So that would explain why its technically 32 vertex shader units, if its using the 32 pixel pipelines. 24 dedicated to fragment processing and 8 to vertex processing as default ???

The programmability features of fragments versus vertices are practically identical now anyway. Why use seperate hardware, when they do the same type of maths? Texture sampling occurs at the vertex level now, just like in fragments. Just create a unified shader engine that can process vertices and fragments and have loads of them, with dynamic balancing based on fragment and vertex processing loads.

[Graphicmaniac]

I just know a thing, and that is for sure because has been said by the president of nVIDIA or something like that to press many and many months ago, probably still around the time of nv30 waiting.

He said they were already working on nv50 and that the unreal engine 3 would be part of the gpu.

I think that could be integrated in hardware or at last some heavily kind of optimization.

[retsam]

No, the next version of DX is gonna be dx9.0d AFAIK. Or maybe its you that just doesn't know ?
but what would dx9.0d bring to the table that 9.0c didnt ..... that was my whole point

[Blacklash]

For now, I'd like to see a 16 pipe 6600 GT style chip with the same shader processing power of the NV40 at 550 on the core, and some real quality ram at a min of 1.20. If that meant dropping the video chip that would be fine with me.

[Razor1]

What ?

Since lighting calculations are based on a vertex shader SH values are calculated from this point to, so the more vertex shaders engines you have the easier it is to calculate SH or Raytracing for lighting, shadows etc.

The programmability features of fragments versus vertices are practically identical now anyway. Why use seperate hardware, when they do the same type of maths? Texture sampling occurs at the vertex level now, just like in fragments. Just create a unified shader engine that can process vertices and fragments and have loads of them, with dynamic balancing based on fragment and vertex processing loads.

The first part of what you were saying with the unified pipelines sounded reasonable, but this last part nope. Programmablity on fragment shaders are alot more flexiable then the vertex shader. At the moment while doing certian things with the vertex shader there is a huge penality, like texture look ups it has an over head of 20-25%. Lighting calculations are still based on vertecies the reason for this is its hell of alot faster. (its actually a combination but the intial light values start with the normals of the vertex and then the fragment shader uses those values and does the per pixel lighting.

Each type of shader is good for its own paticular function because they are structured that way. The nV 50, r500, r600 will be undoubtable much faster then what is out right now so going to a unified system the end user might not notice a speed drop when a program accesses a vertex shader when it should be using a pixel shader or visa versa but it will be there.

[Nutty]

Since lighting calculations are based on a vertex shader SH values are calculated from this point to, so the more vertex shaders you have the easier it is to calculate SH or Raytracing for lighting, shadows etc.

Still dont understand what you're getting at. You could have a million vertex shader units, it aint gonna help much, cos you're mostly always bottlenecked by fragment processing.

At the moment while doing certian things with the vertex shader there is a huge penality, like texture look ups it has an over head of 20-25%.
At the moment yes, it will change.

Lighting calculations are still based on vertecies the reason for this is its hell of alot faster. (its actually a combination but the intials light values start with the normals of the vertex and then the fragment shader uses those values and does the per pixel lighting.
I know how shading works. The reason its faster at the vertex level has nothing to do with the hardware used to do it, or the maths behind it, it's simply that theres nearly always alot less vertices than fragments computed.

Each type of shader is good for its own paticular function because they are structured that way.

Not really, the languages are converging as is the hardware.

Programmablity on fragment shaders are alot more flexiable then the vertex shader.
Again I think you're wrong. Programmable vertices appeared 1st, then programmable fragments appeared. Looping in vertex shaders appeared before fragment shaders. It's fragment shaders that are catching up to the flexibility of vertex shaders, and its pretty much there. There will come a point where there is only 1 shading language for both vertices and fragments, and they will use the same silicon.

[Razor1]

Still dont understand what you're getting at. You could have a million vertex shader units, it aint gonna help much, cos you're mostly always bottlenecked by fragment processing.


Not really depending how the shader is constructed on the fragment shader part will determine the bottleneck, PS 2.0 parrellex bump mapping vs PS 1.0 parrellex bump mapping, they look identical, but the ps 1.0 has almost no overhead just alittle bit more then regular normal mapping. Of course more advanced effects like horizon mapping or relief mapping will be a bottleneck on the fragment shader. But when you have over a million polygons around 2 million verticies in a givin screen, or have only 400k and have to do multiple passes which is the case with more advanced features like PRT and soft shadowing, or self shadowing on a pixel level, even on a fairly optimized engine like Unreal 3, or Doom 3 the vertex engines will be the bottleneck, even on a gf 6. Its all relative.

I know how shading works. The reason its faster at the vertex level has nothing to do with the hardware used to do it, or the maths behind it, it's simply that theres nearly always alot less vertices than fragments computed.

Again this is all relative. Its not the computation of pixels what are the computations doing and how complex are they. If you do SH on a vertex level it will kill todays hardware, doesn't matter what fragment shader your doing.

Not really, the languages are converging as is the hardware.

Its converging yes but by whom? by MS? yes, they are forcing it down in thier next Dx, which on a programmer side might be good because its less work. But on the hardware side there will be a slow down then what could have been expected if they were two different processes.

Again I think you're wrong. Programmable vertices appeared 1st, then programmable fragments appeared. Looping in vertex shaders appeared before fragment shaders. It's fragment shaders that are catching up to the flexibility of vertex shaders, and its pretty much there. There will come a point where there is only 1 shading language for both vertices and fragments, and they will use the same silicon.

True, but I'm talking about the options avialable to the pixel shader is much greater then to the vertex shader (since the vertex shader is only used for the most part as a base where the pixel shader starts from)

This is why there are so many more pixel shaders in hardware at the moment they do more work, we need more of em. And this is where the emphesis of programmability has been for the last 3 years, at the pixel level, as Carmak and Sweeny have said the next few years games are going to utilize smarter polygons (less numbers of verticies, you will see a growth of x2 or so from current games, but this wont' stress these cards at the vertex level)

maybe in the next 2 years tesselation will become mainstream, which in all likely hood will, but we still wont' need more then x4 vertex power for the next 4 years.

The unified solution is only good for one thing making it easier on the programmer.

[Pandora's Box]

550mhz core and 400 million transistors? i dont think so.
directx 9.0d? pffft

[Nutty]

True, but I'm talking about the options avialable to the pixel shader is much greater then to the vertex shader
What options ? I dont see many differences between the 2 at the moment.

This is why there are so many more pixel shaders in hardware at the moment they do more work
I think thats more to do with the fact that pixel shaders are more heavily tied into how an object's appearance is created, so you need to cater for more variations with pixel shaders, whereas you can feed them all from a generic vertex shader.

And this is where the emphesis of programmability has been for the last 3 years
Because fragment shaders were lagging behind vertex shaders in the terms of programmable flexibility.

Theres also the point that vertex shaders worked on Floating point, whereas fragment shaders were fixed point. So it made sense to create custom hardware for them, to exploit the savings in fixed point. But fragment shaders are floating point now too, so there litterally is hardly any difference in what they do, which...

The unified solution is only good for one thing making it easier on the programmer.
.. allows the hardware engineers to concentrate on a single unifed shader engine, instead of creating 2 custom ones, where custom ones aren't needed anymore.

[jAkUp]

32 Vertex Shaders??!! WTF
I call B.S.