Nvidia in 2003

People who hint that they know for certain (MuFu) claim that the NV35 is definitely going to be 256-bit. I would be surprised if it wasn't--if it hadn't already been spec'd for 256-bits, I'm sure NVidia started revising it as soon as they saw what the R300 was capable of.

If the NV40 comes out before the end of the year, I will be truly impressed. It will mean that NVidia will have recovered completely (technically) from the NV30 debacle.

 

Well, since the GeForce FX does not use a 256-bit bus, don't get your hopes up that the NV35 will either. Remember that nVidia will have to revise their clock speed optimizations, as it is highly unlikely for any 256-bit bus board to run the memory at around 1GHz (effective) anytime soon (If the NV35 requires a 12-layer board for 1GHz + 128-bit bus, how many layers do you think a 1GHz + 256-bit bus would require?).

Anyway, I think current benchmarks seem to indicate that the NV30 really isn't haveing that much of a problem with its 128-bit bus. How it stacks up against the R350 (assuming it comes out in a couple of months) is another thing entirely, but just based on how it goes against the 9700 Pro, nVidia really doesn't have much of a reason to go 256-bit yet. What they need to do is support better FSAA modes...

It won't. That, and I think the NV40 will be significantly more capable than the R400. If the R400 is released this fall, I'd like to know how it and the NV35 will stack up. I don't see how it's possible that ATI could have a card that would be noticeably next-generation by this fall, but it should be slightly beyond the NV30 programmability-wise.

 

I'm afraid you're wrong there Chalnoth. My information indicates that R400 will be a very substantial step up from the current generation products both in performance and features.

R350 is functionally close to R300, but faster.
NV35 is functionally close to NV30, but faster.

R400 and NV40 on the other hand, both represent a big step forward in the technology they will introduce (as well as having much higher performance)

 

If there were no minimum instruction counts for each shader version that dx reports back it would be like shooting darts in the dark. After your game ships and new hw just arrives on the scene it might not be able to run your long shader if there were no minimum instr. counts. Some devs knowing hw in advance will choose to write long shaders just for that hw and short shaders for all other cards that developer didn't tested withwhen writing the shaders. In this case the short shaders would be dx minimum length to quarantee that the other hw can run them.

 

Please read my question again, JD.

 

So does mine..

 

Maybe it's to ensure that any card that supports that maximum length will be able to do any DX shader. In other words, they'll be "full shader capable".

 

My guess is that nv35 will be out oct/nov 03 timeframe.

.13u low-k dielectric process
700mhz core ~5.6Gp fillrate
500mhz DDRII or higher ~32GBs bandwidth
256bit bus
support for PS and VS versions 3.0(+ as nVidia would say)
twice the number of transistors in the vertex array
12 layer pcb
STILL retain the FX Flow cooler and molex connector

I doubt we'll see any type of matrox type displacement mapping, however they do it, it wont be compatable. maybe they'll finaly support n-patches, but I'm almost doubting that as well, considering how stubborn they are.

 

nice way of wording that. i take it this means twice the vertex processing power per clock than NV30. not unlike the doubling of vertex shader units in NV25 compared to NV20 (2 instead of 1)

NV35 is going to be what NV30 should have been, in all likelihood. the refresh is always Nvidia's killer product. like TNT2, GF2, GF4Ti.

 

Not to mention expensive cooling systems and a more complex PCB to reach the speeds required to match it's main competitor, the list goes on.

 

Not much of a problem? Even with 128-bit it's slower than it should be:
http://www.beyond3d.com/forum/viewtopic.php?t=4047

Why not? R300 was done ages ago.

R400 will definately be a big step up from R300, from both architectural and performance standpoints. Well, I wouldn't expect performance increase to be quite as much as R200->R300 in most games, but there is a very big architectural change.

 

Well, without so much as a quick glance at the specs, my guess is that they want addresses to fit in a signed 16-bit integer. Why a signed integer? For relative addressing, so that, for example, from the 32,767th instruction in a program, you can do a jump with a negative address, and get all the way back to the very start.

Like I say, I haven't even glanced at the specs, so I've no idea if this even makes sense in context, but it's what springs to my mind.

 

What the... ? You can't leave it at that my friend, we need a hint or two here!

BTW: I ready like the design choices of the R300 a lot. These Art X folks did a brilliant job and now you suggest that the ATI R200 folks can out due them? Blasphemy, I tell ya'!

 

I think it does if you look at any high res benchmark with AA and AF it falls short.

I dont really understand this either. The R300 was faster in some things. And a bit slower then others. How then when they "crank up the speed" with the R350 will the FX have a chance?

You said the same thing about the R300 vrs nV30. We found out that the nV30 is not significantly more capable at all. Slighly yes. Signifcantly? No. And how is R400 going to be behind the NV30 progammablity wise?

 

My guess is it sets a standard on how many bits to allocate in your ASM commands. Although some may argue the IEEE formats do more harm than good

 

I don't get it. :? Why be impressed? Wasn't it supposed that Nvidia would already have NV40 tech ready to go by now? I mean, the NV30 has been delayed for almost a whole year, but the NV40 team should be still targeting its original release date, that can't be to far away like that... I mean, isn't this what was planned at first:

NV30 -> sec half '02
NV35 ->first half '03
NV40 -> sec half '03

am I wrong someway?


Rodrigo

 

I believe NV35 uses a 256-bit for three reasons...

1. They are developing a new PCB for it - why not just use the current board? I doubt the new design is required to allow higher clockspeeds with a 128-bit bus - the current huge, 12-layer design isn't exactly a great starting point. ATi's main reason for moving to a 256-bit bus ASAP was to make them less dependent on advancement in memory technology for bandwidth and it's really paying off now. nVidia will make the same move for the same reason with NV35. Related to that...

2. DDR-II@>500MHz will still be *very* expensive by the summer. Considering the potential clockspeed gains that can be had by switching to a low-K fab process it would make no sense to starve a higher clocked ASIC by sticking with the same buswidth/clock as the 5800 Ultra. To be honest, if they take heed of the backlash regarding the noise of the NV30 they'll only attempt to qualify NV35 at 600MHz or so and tuck the improvements in terms of thermal output under their belt. Should be a nice overclocker that way too.

3. A little birdie told me.

MuFu.

 

Heh,I was thinking the same thing.


However,I think that one of these changes might be due to the Intergrated shader approach since not only would PS & VS function as one but it would also reduce die space,but who knows wonder what they'd do with the extra die space.

 

I'm betting on the unified VS/PS too. It actually makes a *lot* of sense to do that, and even more with VS3.0 where you got to be able to be able to do texture operations in the VS

I don't think, however, that it would give you so much extra die space. It would mostly *significantly* increase performance when either Fillrate/VS is the big bottleneck, and the other is nearly always stalled due to that.

However, I'd guess the R400 could also get something like programmable TruForm ( a programmable primitive processor, basically ) - maybe.

Everything I said is just speculation.


Uttar

 

Or perhaps ATI is going to bite the bullet and go for a TBDR