Will ATi jump on the SLI bandwagon?

PatrickL said:
The presse release Nvidia issued yesterday was a shot in their foot. They perfectly demonstrated why it is not the future with a score so close from ATI best cards.
I know it is in 1024 768 but it is nvidia that provided theses numbers not me.

That press release was damage limitation. Looks very impressive until you find out what one XTPE scores compared to two 6800Us in SLI.
 
PatrickL said:
I know it is in 1024 768 but it is nvidia that provided theses numbers not me.

And again, SLI is about achieving higher res (AA/AF) so i don't see why that means "SLI is useless". That Nvidia released those number probably have a lot to do with that 1024 is the standard res for 3D Mark 05, and thus is the res used for "new world record in 3D Mark" type of things.

What i want to see now is 3D Mark 05 scores in 800*600, 1258*... using different types of AA/AF. That goes for all cards.
 
DemoCoder said:
There is an either-or fallacy going on in these threads. With respect to 3dfx, they went with SLI in lieu of using bleeding edge memory, process, and bus width.

I don't think anyone is arguing that 2 mid-range cards in SLI are more efficient than 1 high range card. But, given that NVidia and ATI are using the same memory, similar processes, similar bus widths, and similar # of pipelines, once these factors are maxed out, the only way to scale further is go SLI.

Once ATI and Nvidia hit the limits of the current memory available, and current transistor densities, how else do you scale performance? 512-bit bus? I don't think so. Tweak the IMR further? The IMR and shaders are already fairly efficient. There's no much left to do except for hax (drop filtering adaptively, etc)

If you're not satisifed with the highest end card each IHV offers, than SLI is the only alternative for more GPU performance.


I know I might get slaughtered again for the following comment, yet here's an extraction of a GP document from 1999:

The rendering process is fundamentally a data-movement operation. As memories have gotten faster and caching
techniques have improved, the performance levels achieved by classical architectures has continued to improve.
These advances have reached the point where today’s state-of-the-art classical implementations are almost
completely performance limited by the width and speed of their external memory interfaces.

There are two ways to build memory subsystems with higher throughput. The first is to increase the clock rate. The
problem with this is that signal integrity issues quickly become a problem. Packaging costs rise exponentially.
Sometimes this is done via a more complex protocol (such as Rambus), which normally has high throughput, but
also higher latencies—problematic for classical graphics architectures. The second method is to build a wider
interface. This also causes packaging, board and system costs to rise dramatically as you go from 256 bits to 512 bits
to 1024 bits, etc. Widening the memory interface leads to inefficiencies for small primitives when, for example,
1024 bits must be read and written to update one sample of a tall-thin triangle.

Many people hope that embedded DRAM solutions will allow all of the graphics memory to move on-chip, thereby
avoiding the complexity and expense of high-speed external memories. There are two problems with this approach.
The first is that embedded memories are “smallâ€￾ in comparison to normal DRAM. For at least a few more
generations of ASIC process technology, a design that is capable of high-quality texture-mapping, z-buffering, and
anti-aliasing at a resolution of 1600´1200 will require several chips worth of memory. The other problem is that they
are “expensiveâ€￾. This is both because they typically don’t get the economies of scale normally associated with
DRAM, and because the rest of the ASIC must be implemented in a process that is DRAM-friendly and, therefore,
not optimal for normal ASIC designs.

Of course was it a marketing bubbleyam whitepaper, but it doesn't also mean that some points are invalid. If on chip framebuffers with high volumes would be cost friendlier even today, then irrelevant of the basics of the underlying architecture anything floating point would be much less of a headache.
 
Bjorn said:
PatrickL said:
I know it is in 1024 768 but it is nvidia that provided theses numbers not me.

And again, SLI is about achieving higher res (AA/AF) so i don't see why that means "SLI is useless". That Nvidia released those number probably have a lot to do with that 1024 is the standard res for 3D Mark 05, and thus is the res used for "new world record in 3D Mark" type of things.

What i want to see now is 3D Mark 05 scores in 800*600, 1258*... using different types of AA/AF. That goes for all cards.

Considering FutureMark's recently acclaimed new policy about drivers and such, I'd be far more interested in seeing how all accelerators behave with optimisations enabled and disabled. Especially if the application will not allow any optimisations in high quality mode.
 
PatrickL said:
The presse release Nvidia issued yesterday was a shot in their foot. They perfectly demonstrated why it is not the future with a score so close from ATI best cards.
I highly doubt that this score was reached on heavily optimised for 3DM05 SLI drivers. It looks more like they've just took 66.51, put two cards in and took the first result they've got with it. IMHO, these are unoptimized scores, they used it just to show that their cards still have an edge in 3DM05 even comparing to X800XTPE on a 8.07 beta (which, imho, contains some sort of heavy app-specific optimizations for 3DM05).
 
I've not read the whole topic here, but isn't it a known & proven fact that up to 256 r300 chips can work in unison?
Won't that capability have been carried over to newer chips?
Surely this would mean that newer ATI cards should be able to cope with dual PEG?
Could it be that ATI are gonna do some kind of spoiler announcement when SLI becomes officially available
"Today ATI announces that its latest driver set enables compatibility of all ATI PEG graphics cards with dual PEG motherboards" or something :?:
 
arrrse said:
I've not read the whole topic here, but isn't it a known & proven fact that up to 256 r300 chips can work in unison?
Won't that capability have been carried over to newer chips?
Surely this would mean that newer ATI cards should be able to cope with dual PEG?
Could it be that ATI are gonna do some kind of spoiler announcement when SLI becomes officially available
"Today ATI announces that its latest driver set enables compatibility of all ATI PEG graphics cards with dual PEG motherboards" or something :?:

Yep R3xx were already scalable for multi-chip sollutions (see for example simFUSION 6500 from E&S - for the professional simulator market).

The possibility of a spoiler from the side of ATI has been already mentioned here by Dave and if there should be such a possibility I highly doubt that it'll be concentrated on drivers.
 
DegustatoR said:
PatrickL said:
The presse release Nvidia issued yesterday was a shot in their foot. They perfectly demonstrated why it is not the future with a score so close from ATI best cards.
I highly doubt that this score was reached on heavily optimised for 3DM05 SLI drivers. It looks more like they've just took 66.51, put two cards in and took the first result they've got with it. IMHO, these are unoptimized scores, they used it just to show that their cards still have an edge in 3DM05 even comparing to X800XTPE on a 8.07 beta (which, imho, contains some sort of heavy app-specific optimizations for 3DM05).

Fun, so basically without any basis, you say that nvidia made a press release for a random score they got and they made no real work on SLI drivers :)
While obviously ati have to use 'heavy app-specific optimizations for 3DM05".
Please post any proof you may have, i am really interested now (besides obviously nvidia told me or we shall talk again about the 256 bit bus on the 6600 :devilish: :)
 
PatrickL said:
Fun, so basically without any basis
Nope, not without any basis. I do have two points you might want to consider.

1. PCIE SLI is relatively new for NVIDIA, i'm sure that they haven't tuned it to a max yet. Why? Simply b/c...

2. ...NV isn't selling any SLI solutions right now! We don't even have motherboards for SLI. So it's very possible that they are concentrating on getting more performance out of their singlechips than from SLIs.

I thought that those considerations are relatively simple to understand for anyone...

As for proof i had on app-specific optimizations in 8.07 for 3DM05 - i suggest you go and read 3DM05 review on hardware.fr, they've posted a graphs comparision b/w Cat 4.9 and Cat 4.10b. From the looks of it i'd say that there is something very fishy going on in 4.10 beta drivers...

It's definately not a proof but it's definately a sign.
 
DegustatoR said:
As for proof i had on app-specific optimizations in 8.07 for 3DM05 - i suggest you go and read 3DM05 review on hardware.fr, they've posted a graphs comparision b/w Cat 4.9 and Cat 4.10b. From the looks of it i'd say that there is something very fishy going on in 4.10 beta drivers...

It's definately not a proof but it's definately a sign.

Did you by any chance read about the memory allocation bug that was present in the previous ATI drivers?
 
carpediem said:
Did you by any chance read about the memory allocation bug that was present in the previous ATI drivers?
I did. I just don't believe blindly in what any IHV says to me about their huge performance improvements. It is certainly possible but it doesn't explain a huge multituxturing fillrate increase in 3DM05 on 8.07 compared to 8.051. This test uses very small textures which surely are fitting nicely even in 128M of VRAM if not even internal texture caches.
 
DegustatoR said:
carpediem said:
Did you by any chance read about the memory allocation bug that was present in the previous ATI drivers?
I did. I just don't believe blindly in what any IHV says to me about their huge performance improvements. It is certainly possible but it doesn't explain a huge multituxturing fillrate increase in 3DM05 on 8.07 compared to 8.051. This test uses very small textures which surely are fitting nicely even in 128M of VRAM if not even internal texture caches.

These beta ATI drivers have been approved by Futuremark for 3DMark05 and will be WHQL in a couple more days.

I think ATI or Nvidia would have to be pretty dumb to use blatent cheats, given how successful the 3D enthusiast community has been at uncovering any cheats when discrepancies like this come up.
 
Well if you have doubts, and we all can understand that, why don't you just ask to FM if they have approved theses drivers or not ?
 
PatrickL said:
Well if you have doubts, and we all can understand that, why don't you just ask to FM if they have approved theses drivers or not ?
I don't believe FM either. They're getting paychecks from NV and ATI, it's not in their interest to argue with them. I'm afraid that they've "learned" that in the days of 3DM03... :(

And then: i have no idea _how_ FM approves drivers. F/e it's completely obvious to me that both vendors are using filtering simplification by default in their drivers. Why doesn't FM consider this as a cheat?

What if FM approves drivers after quality comparision w/refrast only? I hope you do understand that you can optimize specifically for this benchmark without any quality issues?

There's nothing for certain today in 3D world...
 
So how do you explain the 20 % boost on Nvidia hardware between drivers? That one is obviously legitimate for you ?


g-day wrote
Athlon 2.3GHz, 1GB CAS 2 RAM 218MHz, MSI 6800GT, Win 2000

NVidia 61.77 gives 3857
NVidia 66.70 gives 4647

Quite a lift!
 
61.77 was very early on in development. They've been making progress with the shader compiler all the time, so those types of gains are not really to be unexpected in that timeframe.
 
PatrickL said:
So how do you explain the 20 % boost on Nvidia hardware between drivers? That one is obviously legitimate for you ?
I didn't say this. Don't try to speak for me, OK?

Basically, i don't know. But they do seems more legit to me since NV4x is a much newer and more complex architecture than R4x0. So as Dave said this kind of improvements very well may be due to runtime recompiler.

BTW, let's not forget that 66.xx drivers contain new anisotropic optimization algo which is on by default and doesn't present in 61.xx...
 
DegustatoR said:
Basically, i don't know. But they do seems more legit to me since NV4x is a much newer and more complex architecture than R4x0. So as Dave said this kind of improvements very well may be due to runtime recompiler.
.

ATI has been improving their compiler, and their memory/job schedulers. How is this different? It's seems to me that you just distrust ATI's improvements and trust Nvidia's improvements, for no real reason than your preconceptions/bias.
 
Back
Top