AMD: R8xx Speculation
- Thread starter Shtal
- Start date
Fuad is as neutral as Charlie is. If you cant see Fuad's slant in his last five articles then no convincing by me can make you see that now. Lets agree to disagree on this topic, others have well and truly see Fuad's colors, if they had also mistankely thought that he was "neutral".
The last article outside of what I arlready stated, I don't see how his view's were anything else. Also if you read his previous articles, he is stating what I said, the new low- mid range cards are going to be more then the previous high end cards but they won't perform as well over all.
One about the gt300 being faster I saw nothing in there that was outright down on ATi cards, other then him stating one is faster then the other, not only that his article was just passing along info, nothing expounded upon or anything of the sort.
His Dx 11 article which was stating ATi is pushing Dx 11 seems pretty neutral.
Easy enough just have to wait to see which of the two actually comes out true
I am starting to have respect for the fanbase ATI has built.
Nice logic there: First you imply that one must not judge someone who one does not know personally and then you actually judge me even though you dont know me personally.
Thats actually good advice and I have to admit I don't try too hard to be nice.
You're both german, fight it out over at hardware-infos I say!
You get preferential support, time is money.
Broken Hope
Regular
Seen a few retailers in Europe that have the 5870 at 350/360 euros which is like over $500. I know we tend to get ripped off here in the EU but there's no way I'm paying over £300 for the 5870 so I hope the launch day prices are more reasonable.
Also appears there will be a shortage.
http://translate.google.com/transla...r-une-ati-hd-5870&sl=fr&tl=en&history_state0=
Also appears there will be a shortage.
http://translate.google.com/transla...r-une-ati-hd-5870&sl=fr&tl=en&history_state0=
It isn't grater. It starts in 50%...
The anisotropic filtering still lacks samples on RV870
ATI still gets away with this stuff after years...
I'm sorry?
AF lacking samples?
If you're talking about AA, you are grossly mistaken and will be pleasantly surprised.
---------------------------
why translate when it's in english?
http://channel.hexus.net/content/item.php?item=20332
I must have have mixed some of Seiler's description and Forsyth's together mentally. I had thought the full amount of the rasterization remained with the minimal front-end solution.
That would be what I was commenting about when I mentioned the lower range.
There would be additional costs in the case of tesselation spawning new triangles that might worsen bin spread, I would think.
It would also dictate a specific style of front-end.
Programmers could not opt to have a heavy front-end in the multi-chip case, and they may find themselves constrained by this.
Running the front end on both chips would possibly allow this choice to remain.
Yes and no.
It depends on just how naive the solution is.
Worst-case, a lot of the necessary data resources do not have local copies on the second chip, and then the entire thing is throttled by the interconnect.
The way back-end cores eagerly snatch up the next available tile was not described as taking into account any locality.
This is probably fine in the single-chip case since it's all the same memory controllers and ring bus.
It can incur additional costs if this causes self-assignment to hop chips.
Would these buffers be in local memory per-chip or in the L2 caches?
An additional concern is that this turns into a streaming problem when the remote cores are aware that the additional vertex work is available. (edit for clarity: so we must factor in synchronization costs that do not exist otherwise)
The most latency-tolerant methods would lean most heavily on bandwidth and buffers to work their magic, and we have an unknown ceiling in interconnect bandwidth. It's probably safe to assume interconnect bandwidth << DRAM bandwidth.
I figured alignment issues and line problems as falling in the noise.
I think reading from a bin in memory would be done in chunks anyway.
I have my doubts about how similar they can be.
Any low-level event that leads to waste in the multi-chip case something that, even if rare, is in my figuring likely to be 2-10x as expensive to handle versus a waste problem that stays local.
This is why I am reluctant to assume that something that is 10% of the load in a single-chip scenario stays at 10% with multiple chips.
Assigning a PrimSet to a core can take possibly tens of cycles with one chip.
Assigning triangles to bins can take place at the full bandwidth of the chip DRAM bus.
A back-end thread detecting that a bin is ready would take tens of cycles, and reading bin contents in the back end can use full bandwidth.
About half the time with multi-chip situations, assuming completely naive assignment, these assumptions will not be true.
This would come down to the complexity and amount of independent nodes in the dependency graph.
In the scale of granularity where per-frame barriers are coarsest and per-pixel or fragment is finest, coordinating at a render state might be medium-to-coarse synchronization. It would be additional synchronization, and this would be a performance penalty even with one-chip.
Some of this may be unavoidable regardless of scheme used, as those buffers eventually have to be used and so much of that data will need to cross the interconnect.
It might be that this can safely be done by demand streaming to each chip or perhaps a local copy of each buffer will exist for each buffer in each memory pool.
The bin sets are stored in main memory, though.
The Seiler paper posited the number of color channels and format precision as the factors in deciding tile size.
A bin's contents could be streamed from a chip's DRAM pool based on demand, so why would this impact the tile size?
Granted, if for some reason the bin were on the other chip's memory pool due to a non-NUMA-aware setup, costs in latency, bandwidth or memory buffering would be higher.
Actually, if the scheme is that naive, it wouldn't know to add additional buffering and the chips would just stall a lot.
I'm talking about running the exact same front-end setup process on both chips simultaneously, so each operation would be performed twice. There would be two bin structures, one per chip, and each chip would get portions of the screen space so that each chip can avoid writing triangle updates for non-local bins, and cores would not try to work with data from the other chip's DRAM pool unless absolutely necessary.
This is what I was talking about.
The control core that assigns PrimSets to other cores can do so in a manner that fits well with a possible implementation of the ring-bus.
The other cores don't magically become aware of the assignment without some kind of ring-bus transaction.
I've been discussing Intel's own software rasterizer, though. I'm not clear on just how much can be set by a programmer not messing with Intel's driver and all that.
Sure, if a developer rolled their own solution they could do what they want.
I think that any multi-chip solution from Intel would include software that was modified so that as much work gets done locally as possible, even if at the cost of duplicated computation.
Last edited by a moderator:
We've just got to have a caption competition
Check "General Discussion". We don't want to sully this thread.
He means anisotropic filtering. It looks like there are no improvements for the filtering quality and all these pictures of the new AF flower (D3D AF Tester) are a bad joke.
It's the same game as every new release: With syntethic tools and colored mipmaps we see an amazing full trilinear quality, but in the real apps (games) it's still crap.
So that means that tesselation is not a DX 11 specific feature?
That's a bit of a simplistic assessment, to say the least.
Similar threads
