NVIDIA to release 10 new cards before NV30?

[Verge]

all the other 6's and 8's are easily distinguishable.... why are only those 2 numbers screwed up some bad... it's obvious that the 2 numbers in question are 8's... but why don't they look like the other 8's on the page ??

 

[Bigus Dickus]

all the other 6's and 8's are easily distinguishable.... why are only those 2 numbers screwed up some bad... it's obvious that the 2 numbers in question are 8's... but why don't they look like the other 8's on the page ??

Some 5's look like 6's, some 6's look like 8's, and one 8 is similar to a 6. Hardly obvious, for any of the numbers other than 0, 1, or 2. I think my interpretation (and BoardBonobo's) is the most logical one.

 

[Ilfirin]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

 

[alexsok]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

Thx for the link m8!

That's an intresting paper!

But I haven't seen it there... how did u find it?

 

[Ilfirin]

It was 4 down from the top on the left side of developer.nvidia.com

 

[alexsok]

It was 4 down from the top on the left side of developer.nvidia.com

Yeah, I found it myself a sec ago, but i think it's the same paper as before in that section...

 

[demalion]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

Could you check this link out and tell me if there is any difference? Don't feel like digging up my install CD for PowerPoint if it isn't necessary.

http://developer.nvidia.com/docs/IO/3121/ATT/CineFX Overview-1.3.doc

 

[Ilfirin]

It's possible that I missed it before, if that is the case it looks like a lot of people in this forum missed it too ;p

For the past few years I have been checking that site multiple times a day and this would be the first case of an article slipping past me if that is the case.

demalion, All sorts of things.. Ill list some (copy and paste)
DX9 / R300
1 shader (1-4 bones)
Branching is per-object
Still have to segment model into 1-4 bone groups
Draw separately

CineFX
1 shader
Branching is per-vertex
No need to segment model
Loop is done conditionally on a per-vertex level

Pixel Shaders:
R300 = NV30 = 16 textures
R300 = 32 Texture Instructions NV30 = 1024 texture instructions
R300 = 64 Color Instructions NV30 = 1024 Color Instructions
R300 = 12 temp storage NV30 = 64 temp storage
R300 Instruction Predicates = NO NV30 = Yes
R300 Unlimited Dependent Textures = NO NV30 = Yes
R300 Swizzling = NO NV30 = Yes
R300 Advanced Instructions = NO NV30 = Yes
R300 Conditional Write Masks = NO Nv30 = Yes


Precision:
DX8/R300/NV30
Max: 32/96/128
32-bit color = true/true/true
64-bit color = false/false/true
128-bit color = false/false/true
Format = INT/FP/FP

16-bit floating point format is s10e5, or 1bit sign, 10 bit mantissa, 5 bit exponent (-15 bias)

32-bit floating point format is s23e8

Nv30 features:
Render to vertex array (Displacement mapping, particle systems)
Ray tracing
floating point cinematic precision compositing


Interesting marks on the last slide:
Where AA is in the DX7 and 8 slot and is fixed function, pixel processing is in the Nv30 slot and is programmable. This mean you have control over the AA in the nv30's pixel processing?

Also under Nv30 is OpenGl 2.0 and DX9 support.

 

[DemoCoder]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

That presentation has several bugs, some may be intentional, some unintentional.

First, they still say that NV30 vertex shaders can do up to 1024 static instructions and 65536 with looping, but Cass Everett of Nvidia says 256 static instructions and 16384 with loops.


Then, there is the slide talking about 128-bit FP. They list the R300 has having "Max precision of 96-bits", but then underneath the columns for framebuffer precision, they don't have either 64-bit or 128-bit "checked"

On another slide discussing pixel shader features, they say the R300 doesn't do arbitrary swizzling. Well, according to the last beta version of DX9 I have, DX9 requires arbitrary swizzling. So, either this was removed from DX9 in a version newer than mine, or that would imply that the R300 is not DX9 compatible, which I find hard to believe.

Another alternative is that they don't support swizzling in hardware, but the ATI driver compiles expands swizzling instructions into 4 color ops at runtime to emulate. Sounds fishy.



Ok, that's the bad stuff, now the good stuff:

o Actual info about the floating point formats used!

o Advanced Graphics Processing - Render to Vertex Array: What is this!?!?
Could this be the per-primitive processor we've been hearing about? They list as features "displacement mapping" and "particle systems"

In a later slide, they have the "displacement mapping" box color coded green which means "full FP programmability". This would seem to indicate programmable displacement mapping. However, since this is also listed under the "Render to Vertex Array" section along with particle systems, it seems to indicate that it is not a fixed function tesselation, but is fully programmable.

 

[alexsok]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

Could you check this link out and tell me if there is any difference? Don't feel like digging up my install CD for PowerPoint if it isn't necessary.

http://developer.nvidia.com/docs/IO/3121/ATT/CineFX Overview-1.3.doc

Considering that it's in the same section as the previous paper was and no annoucements were made on their page, u can safely assume that it's the exact same paper as before, only renamed to better suit the content of the paper

 

[alexsok]

Not sure if you guys have seen this article yet (it is marked as July 21st.. but I am almost certain it wasn't there yesturday)-
http://developer.nvidia.com/docs/IO/3122/ATT/CineFX_1.21.ppt

It has several direct comparasons between the r300, DX9 and the NV30. So even the frame buffer is 128-bit with the NV30 eh (not with DX9 and the r300)? Very future oriented.

Kinda indirectly says that it will support OpenGL 2.0 as well.

That presentation has several bugs, some may be intentional, some unintentional.

First, they still say that NV30 vertex shaders can do up to 1024 static instructions and 65536 with looping, but Cass Everett of Nvidia says 256 static instructions and 16384 with loops.


Then, there is the slide talking about 128-bit FP. They list the R300 has having "Max precision of 96-bits", but then underneath the columns for framebuffer precision, they don't have either 64-bit or 128-bit "checked"

On another slide discussing pixel shader features, they say the R300 doesn't do arbitrary swizzling. Well, according to the last beta version of DX9 I have, DX9 requires arbitrary swizzling. So, either this was removed from DX9 in a version newer than mine, or that would imply that the R300 is not DX9 compatible, which I find hard to believe.

Another alternative is that they don't support swizzling in hardware, but the ATI driver compiles expands swizzling instructions into 4 color ops at runtime to emulate. Sounds fishy.



Ok, that's the bad stuff, now the good stuff:

o Actual info about the floating point formats used!

o Advanced Graphics Processing - Render to Vertex Array: What is this!?!?
Could this be the per-primitive processor we've been hearing about? They list as features "displacement mapping" and "particle systems"

In a later slide, they have the "displacement mapping" box color coded green which means "full FP programmability". This would seem to indicate programmable displacement mapping. However, since this is also listed under the "Render to Vertex Array" section along with particle systems, it seems to indicate that it is not a fixed function tesselation, but is fully programmable.

It's all fine, it's 1024 static instructions for pixel shaders and 256 for vertex shaders, just like cass said.

 

[Ilfirin]

First, they still say that NV30 vertex shaders can do up to 1024 static instructions and 65536 with looping, but Cass Everett of Nvidia says 256 static instructions and 16384 with loops.

No it doesn't, it says 256 instructions 256 loops for vertex shaders on the NV30. The 65536 number was always right.

Then, there is the slide talking about 128-bit FP. They list the R300 has having "Max precision of 96-bits", but then underneath the columns for framebuffer precision, they don't have either 64-bit or 128-bit "checked"

That is because the framebuffer of the r300 is still 32-bit, as is what the DX9 spec calls for. Only the internal stuff is supposed to be high precision to meet the DX9 spec.


For the Swizzling, I am betting that is some technicality.. possibly a CG specific version of swizzling that the R300 doesn't support.

Some of the slides seem to lean towards possible programmable primitive assembly, but that might just be my optimistic mind.

 

[AzBat]

Can't believe I'm going to reply and nitpick this, but it's bugging the hell out of me.

I would have to agree with BoardBonobo.

First examine the NV28.

I don't believe that's an '8', but I'll continue and explain why. Before you reply, look at the slide with a resolution of 640x480.

It looks at first glance to be 86 million,

That's because it is...

but then you have to cross check how closely that matches other numbers. The "8" of the supposed 86 isn't anything like any other 8's anywhere else on the slide.

Yes, it is. Look at the '8' in NV18(26M) and NV26(82M).

Bit-wise, it's much closer to a "6" than anything else.

Yes, the '6' is missing one pixel compared to the '8', but in the slide all the 6's are the same.

From a thorough check of all the digits, it looks like 8's and 3's are very difficult to distinguish.

Agreed.

The "3" of NV30 and the "8" of NV18 look identical,

That's because they are identical. This means they are both 3's. That makes it NV13, not NV18. This corresponds with the fact that they are both the same '3' as in NV10(23M). As for the NV18, the chip above NV11 is actually the NV18. The '8' in the NV18 matches the '8' in NV26(82M).

but there are other places where two known 3's don't match identically.

Such as?

It is logical to conclude that numeriacal characters aren't duplicated perfectly from position to position, but vary slightly in their bit makeup. But, the same thorough check reveals that never does a known "8" look anything like a six (with one caveat, the NV17's 28 million, where the 8 does resemble 6's elsewhere, except for the missing bit in the lower right that none of the other 6's have, and it has the corner bit in the upper left that none of the other 6's have). The first digit of the NV28's transistor count does.

I agree that is an '8' in NV17(28M). The missing pixel is at the bottom right instead of the top left. The '8' in NV11(18M) is also done the same way. I don't see anything wrong with this.

Also, let's look at the "6" of the supposed NV26. Looking at other places where there should be a known "5" (such as NV15) we see that 5's look like 6's. This would also explain why it looks like NV26 instead of NV25. The "6" of NV26 is a "5", and it is NV25.

Actually, my belief is that the NV15 is actually NV16. Looking at the slide at the lower resolution it's absolutely a '6'. Now you're probably saying there isn't a NV16. Agreed, I just think they had a typo, because I think they made the same mistake again with the number of transistors, 26 instead of 25. This makes more sense then saying that the numbers actually look like 5's. Is NV26 also a typo? It would have to be unless they haven't shipped it yet.

Then examine the NV18. The first digit is going to be either a 3 or an 8, based on comparisons with other known digits in other positions. It wouldn't make sense for it to be 81 if the NV25 is only 66. Therefore, it must be 31 million, which is precisely the increase from the NV17 as the NV28 has over the NV25.

If it's a '3' then then the '8' in NV18 is also a '3' since they are definitely the same number. This goes back to my first point that it's NV13(31M), NV23(86M) and NV30(120M).

Conclusion?

I won't make any. My original intention on posting was in deciphering the numbers. Before any conclusions can be made the numbers need to be correct.

Tommy McClain

 

[Basic]

DemoCoder:
They must have changed it between your and mine download then. Because i just downloaded it and it says 256 static, 256 loops, 65536 instructions, for vertex shaders.

128-bit FP. Might refer to framebuffer/texture format with all the usual operations on them. (Filtering on textures, alphablend on output.)

Agree that the swizzling sounds fishy.


LOL about the "render to vertex array", it was just a few days ago that the question came up at www.cgshaders.org, and cass@nvidia said: "You can render to a float4 vector texture, yes. Not sure about the rendering to vertex array - though that sounds interesting."

It can be usefull if you want to do physics in the texture pipeline, or geometry where you want to save the state between frames, or somehow fake vertex shaders with texture sampling.
I've wanted to do this kind of tricks since DX7.


demalion (and axelok):
No it's a different document.


Ilfrin:
DX9 demands 128 bit FP external buffers, but not in the "normal" framebuffer. And you don't need to support blending when writing to these FP buffers, and you don't need to support filtering when using them as a texture.


Btw, all pages says "NVIDIA CONFIDENTIAL", are we supposed to read this?

 

[Ilfirin]

DemoCoder:
Ilfrin:
DX9 demands 128 bit FP external buffers, but not in the "normal" framebuffer. And you don't need to support blending when writing to these FP buffers, and you don't need to support filtering when using them as a texture.


Btw, all pages says "NVIDIA CONFIDENTIAL", are we supposed to read this?

Yes, that's what I said. The 4 internal render targets that are used with DX9 are still internal (to the user that is), there is only 1 external frame buffer.

And for the Confidential part, I thought that was funny too ;p

 

[Basic]

Ah, you might find that when most people talk about internal precision, they mean internal in the chip. I thought that was what you meant.

 

[psurge]

According to that PPT it looks like the AA method is programmeable as well - at least the box for CineFX AA stage of the pipeline is colored green...

Serge

 

[DemoCoder]

According to that PPT it looks like the AA method is programmeable as well - at least the box for CineFX AA stage of the pipeline is colored green...

Serge

I could see two ways of doing that with DX9 pixel shaders:

#1 you can AA textures youself by taking multiple samples according to whatever algorithm you want (limited by the number of dependent texture reads you can do)

#2 procedural textures AA'ed via similar method

#3 assuming a packed 128-bit format of the MSAA buffer, the downsample stage could be handed by a pixel shader reading the packed buffer from a texture and writing out the downsampled result

As for generating multiple edge samples, I haven't quite figured it out yet, since you'd have to emulate scan conversion in the pixel shader. I'm sure you could pass the triangle parameters to the pixel shader and have it generate subsamples using the DDA or Bresenham, but I think performance would suck.

 

[psurge]

DemoCoder,

Fair enough, but they have put this stuff in a box (labeled "pixel processor") separate from the "pixel shader 2.0" box. I guess it's just a marketing doc and doesn't really mean squat, but it reminded me of the programmeable AA 3dlabs is offering with the p10.

Maybe this means programmeable number of samples, sample patterns, filters? (I was never clear on what exactly the p10 can do in this area).

BTW this is all from the last slide of the powerpoint presentation.

Serge

edit: From the diagram it definitely does not look like they are talking about texture filtering. have you looked at it?

 

[Ilfirin]

it reminded me of the programmeable AA 3dlabs is offering with the p10.

If the nv30 is indeed going to support OpenGL 2.0 (as the presentation says), then this is very likely.