Originally Posted by Macadamia
GRID only plays nice with Crossfire/SLI after patch 1.1. Sampsa?
theres already a new patch 1.2 out
New Race Driver GRID PATCH 1.2
http://www.racedrivergrid.com/?territory=EnglishUK
Patch 1.1: Download (188mb)
Patch 1.2: Download (192mb)
regards
[Review] Core i7 920 & UD5 » Here!! « .....[Review] XFX GTX260 216SP Black Edition » Here!! «
[Review] ASUS HD4870X2 TOP » Here!! « .....[Review] EVGA 750i SLi FTW » Here!! «
[Review] BFG 9800GTX 512MB » Here!! « .....[Review] Geforce 9800GX2 1GB » Here!! «
[Review] EVGA GTX280 1GB GDDR3 » Here!! « .....[Review] Powercolor HD4870 512MB GDDR5 » Here!! «
Agreed, they had mentioned that improvements were made for multi GPU in 1.1 (something I mentioned earlier in this thread). Because he didn't mention what version of Grid demo he used I suggest that he tries Grid Demo 1.1 instead. I am not sure he's aware of this but there are 2 versions of Grid demo, v1.0 and v1.1. I haven't found a demo with v1.2 as of yet. There is no mention of patch 1.2 working on the demo or not. However, a test like this should be done using the retail version (that way he would have the current patch).GRID only plays nice with Crossfire/SLI after patch 1.1. Sampsa?
Edit:
I would also like to know what drivers were used in this test, for clarity.
Last edited by Eastcoasthandle; 07-15-2008 at 07:40 AM.
[SIGPIC][/SIGPIC]
24 core GPU in 2~5 years using the new HYDRA bridge chip by Lucid, enough said!
Listen to the long interview.
.
Power and heat.
OT: First there were smithfields, then there were penrynspower and heat issues subside when cores become more efficient.
I hope someone compares stuttering on both R700 and GT200 before the Mayan calendar ends.
Perkam
Likewise.I hope someone compares stuttering on both R700 and GT200 before the Mayan calendar ends.
Perkam
Would be interested to see how much of this is fixed on the driver vs. the hardware vs. the software. The 4X series seems to have a clear advantage over its predecessor. I wonder of the GTX200 series can claim the same? Either way I am looking forward to sampsa's final review on the subject.
Me as well, did he give us a date or approximate time he may be completed with said tests?
he has no r700, had to return it.
I think its correct that only 30 frames are not enough to make a correct conclusion. Ofcourse, like you say.. You can see a pattern. But its also possible that that pattern only excists in the first second of the test.
What I think is weird, is that the 4870X2 has about the same variance in your graph as the 2x 4870 XFire. The CrossFireX port on the R700 should lower the microstuttering even more then with normal crossfire..
why? plx chip adds latency....single gpu would have pci-e bus only...so minimal data will be the same, but when heavy data is exchanged, the lower latency of sideport will let r700 shine.
Why? Cause I heard from CJ that with the r700 sideport the microstuttering would be gone.
So then I made the assumption that microstuttering still excists in the 4870 crossfire (2 cards), even though I havent heard many people complain about it.
Edit: And yes, I know assumptions can be bad.
Sideport is still there on single gpu's...there is no longer ringstops for that. SO it should be the same for Crossfire via mobo pci-e, or crossfire via vga board pci-e...either way you are no longer using memory resources for multi-gpu communication, and using the side port instead. R700 excels due to lower latency due to less physical distance between the cards, as well the PLX chip should offer at least 16-lanes of pci-e 2.0 between the cards in combination with the side port, whereas some mobo's will not give the same connectivity.
there's moer issues at play in "microstutter" than anyone is really aware of, other than maybe myself and those that built the cards...and even then I doubt they are putting all that much work into it...you can only fix what's broken, you can't fix something not broken!
Last edited by cadaveca; 07-15-2008 at 01:54 PM.
Cadaveca, you allude that microstutter is a not a 'broken' problem. So what you is your take on it then?
Design errata
Isn't errata usually something that is broken?
You are over-simplifying. Errata is used for corrections to a program's code, it does not modify the fundamental functions of the program. A flaw, on the other hand, in the program requires a modification to the fundamental functions of the program and is what is called "broken" in layman's terms.
Perkam
Well keeping it simple is usually best
Broke is broke. You are just describing the method to fix it. If its a code problem, what code? And why not apply those fixes to the 3xxx series also?
I dont think many would consider the problems that the Phenom had originally as not 'broke'.
TLB = Flaw i.e. something you can fix but not without recalling the product. Microstuttering = Errata, i.e. it can be fixed with architectural updates and driver optimizations without need to recall the product.Well keeping it simple is usually best
Broke is broke. You are just describing the method to fix it. If its a code problem, what code? And why not apply those fixes to the 3xxx series also?
I dont think many would consider the problems that the Phenom had originally as not 'broke'.
The reason the same cannot be applied to the 3870 was because the updates to the Xfire were not available on the 3870X2 but are now on the 4870.
Perkam
Perkam,K10's TLB problem is an errata and yes it can be fixed without a need to recall a whole line(it is/was done via TLB switch in BIOS).AMD did fix it in in hardware(B3) without the penalty the software fix brings.
As for the microstuttering with multi-gpu it's all around a very complex problem like cadaveca said.
A temporary fix if anything. It still required a recall (to b3) to fix the problem permanently. The TLB fix was more of a TLB patch.
Perkam
Just arguing semantics.
AFAIK,B2 Phenoms are still sold and AMD is not accepting RMA's for it.recall ,n.:
A request by the manufacturer of a product that has been identified as defective to return it, as for necessary repairs or adjustments.
So you used a wrong word in your post(recall).
The B3 is a stepping that fixed B2's TLB problem,AMD never accepted B2 and in turn handed over B3s.
B2s work fine even without the patch and the chances you encounter the erratum(since that is an erratum,contrary to what you said),you need to run very specific multithreaded code.With the TLB patch ,you can't hit the problem even in that case.B3 has a hardware fix with no penalty at all.
Microstuttering effect is not an erratum.
As are you. Over iterations of Crossfire they have solved many issues, and what we are left with now is about as good as it can get. That start-up multi-gpu accelerator, to me, sound more like a dispatch processor...I question it's worth. I mean, it could be useful, but I need far more details than what has been given so far. They aren't even making the chips..they are just liscencing the tech!
Anyway, First TMDS chips had a big flaw. They did not provide enough bandwidth(X800/X850). The next interation they doubled up the chips(Crossfire wasn't able to do dual-link DVI at first, a hardware requirement for 2560x1600 etc, resolutions.)
So, it was still bandwidth limited, and due to it's nature, added input lag. So they moved into the gpu for the interconnect, using a ringstop for extra inter-gpu communication. This also allowed them to use Crossfire for HDR, etc...as the first method using the TMDS chips presented issues as only final frame was composited together by TMDS in most rendering modes, Dis-allowing post processing in some situations.
As we have found out, a single ringstop was not enough. Even with 16x +16x pci-e lanes to the cards, allowing 8x to card, per card, and 8x for communication, bandwidth was still at a premium.
Using a ringstop meant that resources for memory control were also used for multi-gpu...we instantly can never have 2x performance gain because of this...all teh way from 2400XT to 3870x2.
So, now we have RV770...well...details are sparce at the moment, but we know that memory control is not used for intercommunication, and that this communication now happens over the "side port". What this port is composed of, or capable of, we won't know for a bit yet.
The only reason I think I know what's going on is due to my digging into this issue far more than anyone else...I have been complaining of this main problem with multi-gpus since it started...you can look back to my posts here about the TMDS chips being an issue. I've been following this for years now...
Anyway, it may not be an errata, per se, but it is definately a hardware issue. Like errata, specific workloads trigger the problem...and like some errata, it cannot be completely fixed, without hardware changes. Rv770 is the start of this change...and I expect one more major change before I see what I think is right...of couse, I'm not in the industry, nor an engineer, like you, I'm making assumptions. And I don't mind being an ass over it.
Last edited by cadaveca; 07-15-2008 at 05:30 PM.
How am I arguing semantics?
It was broke. The frame sync was bad. In order to fix it they had to make a design change. I dont care where they had to make the change, or how, they still had to change something in order to fix it.
You say it wasnt broke, but you say its a problem
Problem, broke, whatever.
So to summarize your post containing mostly nothing relevant, you believe the fix to the microstutter is from the sideport?
I say it wasn't broke, as they knew the problems the design would pose before it was fully taped out. At the beginning of Crossfire, they(ATI) were making gpu's in a mini-fab, so at some point someone said "OK let's go with it". You are calling it broke becuase it didn't work...that's arguing semantics.
As such, I cannot call it broken. Not ideal, yes....it was a design decision made for "whatever reason".
And while you may think my post contains nothing useful, it does highlight exactly what they think CAUSES microstutter, and how they have decided to fix it.
Posting Permissions
Bookmarks