ATi Radeon 1950 XTX

so the competition can't formulate a response fast enough

 

Well the x1950 is at most 5-15% then 7950 gx2 not 100% in most situations, at least without crossfire and quad sli. But hardwarezone has it that the gx2 is always faster, and vr-zone has it the x1950 is faster. Just have to wait on more benches for now.

 

There's a few reasons there. One of which is "fairness" to all the different journalists. By making them wait until the same time/day you take some of the competitive pressure out of trying to get done and up "first". Which isn't really great for us either, as a fast review for competitive purposes is likely to be less accurate than we'd like it to be.

The IHV also gets a bigger PR "bang" to have the entire hardware web talking about their product all at once.

Plus, with the mantra of "hardlaunch" that both IHV's have adopted, how can you assure you can achieve that if any site can publish their "review" willy nilly whenever?

 

I'm curious as to why the HardwareZone preview came down while the VR-Zone is still up without any issues.

I'm also still a bit unsure about the performance. I did not expect the X1950XTX to be able to beat a 7950GX2, I thought it'd be very close and it'd help justify the price but beating it? I'm still not sure I believe the VR-Zone or for that matter the HardwareZone numbers.

 

Personally, I think anyone who relies on one sites numbers, and only one sites numbers, is asking for heartache. Unless they are B3D's of course (he said obligatorily).

Dunno why one is pulled and one not. Maybe one pulled out of respect when ATI squealed and the other didn't.

Or maybe one went after the other went, for competitive reasons, thinking that would absolve them, but then had their NDA waved in front of their faces while the other didn't have an NDA to be waved at them.

 

Hardware Zone used a much slower FX-55, and the 7950GX2 was set to "Quality" instead of "High Quality".

VR-Zone's test was conducted using an X6800, and their 7950GX2 was set to "High Quality". Nvidia's "High Quality" setting makes it close to or matching ATI's image quality, but at a serious performance hit.

Both sites seem to have valid results to me.

 

VR-Zones preview is also taken down. Luckily it can still be found here http://resources.vr-zone.com.sg/Shamino/1950/ It won't be long before that one's gone too.

 

R300King!, check your PMs please.

 

quick q about the nvidia gx2

it says Pixel Shader Engines 48 x 2

that means 48 ps in total not 48 on each chip(aka 96) right ???

 

24 per core 48 per card.

 

One reason the results are suspect are due to prior reviews between the GX2 and the 1900xtx. If you look at this Rage3D GX2 review taken in late June, you would at least expect to see similar performance results between the 1900xtx and Gx2. When you have wide variances it's easier to make sense if you have more previews/reviews to compare against.

 

They probably count mini-ALUs along with full pixel ALUs; in this sense, there's 48 processing units in total

 

No, G70 has 2 full-ALUs per each pixel pipeline. And each ALU has it's own mini-ALU. So G70 = 48 (MADD) ALUs + 48 mini-ALUs.

/edit: The question is what we treat as pixel shader processor/engine.

 

Each ALU can't do the same thing per clock, though, depending on what the chip is doing. If it's texturing for example, you can stall the other sub-ALU completely. 24 is probably the best number to use, for G71, IMO.

 

Rys where did you hear that second ALU can stall completely? Thats totally contrary to what I have seen from testing. I'd say 30% is a more accurate representation.. I would say 1.5 MADD capability is completely fair. Also I have seen some tests which hint that G70's mini ALUS do feature some ADD capabilities.

 

Thanks for that.

 

I think he means that it stalls for the texturing operation.

 

I realise that. But I just dont entirely believe that is fully accurate. Which is why I wonder how Rys came to that conclusion. But maybe an ALU discussion of the G70 is better served elsewhere though as its beaten to death.

 

IIRC it won't stall the second unti during normal texture operations, but might under dependant texture ops.

 

Indeed, since the second unit is serial to the first. If the first sub-ALU has to help with the texture address calculation for a dependant texture op, you stall the second.

And if memory serves, certain filter states can achieve the same thing.