NV31 closer to NV35 than NV30? - More pipeline mysteries.

I think more correct to say - do not give credit to concrete person(s) who first stated that here 4х1/2х2 scheme dependant from mode in nv31 and 2х2 always for nv34 becouse FORUM itself didn't own copyright on concrete person(s) messages.

but this is detail's...

another way of leak - on russian forum ixbt.com i post this info slightly before beyond and for examle may be here someone from our russian forum who translate info and send to inquirer (as somethimes info translated and posted here in someway)

realy - its very easy to any developer that have this cards and make expirements and come to such decision. so its strange to try to copyright
this REAL specs becouse ANY can easy obtain its itself. its simply fact. somethin like say - today is 5 degree celsius on street. please credit me if you also measure this later or listen about this from friend.

i was ensure in this and come to this conclusion in first 15 minutes of handson on 31/34 cards and no something special for that - simply one of synthetic fillrate benchmarks that enables change number of textures and filling mode (combiners/shaders of diff vers) as i want...

 

Well, it would make sense to protect the NV3x real specs if they were microcode programmable, but that nVidia didn't want to tell because the whole implementation is screwed

"Yes. We got a lot of 3DFX tech in the NV30. What? Oh, well, about half the die. What features? Just all the broken things."

But anyway, if that wasn't the case, I indeed can't quite understand why nVidia wants to give so little detail...
Maybe they hoped Beyond3D & developers would shud up


Uttar

 

It makes some sense.

Have nVidia ever told people that 2x MSAA practically disabled Z-buffer compression on the Geforce3?

 

Hyp-X: Eh, no. And I didn't know about it, either Is it disabled with 4x MSAA too?

BTW, I really wonder what's the percantage of broken functionality on the NV30... MuFu said it had quite much, but nothing more...


Uttar

 

It's not disabled just ineffective. It calculates the gradients improperly, so it only works on surfaces with nearly constant Z.
4x is ok because it's ordered.

Judging by the improved speed of 2x this might be one of the things fixed in nv25.

 

Becouse VLIW array of units with microcode is most efficent way for implement todays shaders in paralel (not pixel only but vertex to)probably now we always will be dependant from task in questions of configuration (2х2 4х1 and so) so we need to switch on descriptions like:

up to 4 color per clock stored
up to 8 depth/stencils stored
up to 8 texture values fetched or up to 4[4] fp32/fp16 operations performed
up to 8[4] integer operations performed

and so on

its resembles to me ideas of 3dfx "texture processor"

so we need to carry different tests based on real shader sets like we measure CPU now, becouse they shedule dynamicaly couple of instructions and we cannot make any clockbased decision...

 

Isn't it 8 fp32/fp16 shader operations per cycle (with no z/stencil writes)? This link from Tech-Report: http://www.tech-report.com/news_reply.x/4782/5/ says 8 shader ops per clock.