You forgot this one:
Apple LED Cinema Display which comes with a Mini-DisplayPort connector.
The perfect companion for the Radeon HD 5870 SIX
AMD: R8xx Speculation
- Thread starter Shtal
- Start date
You forgot this one:
Apple LED Cinema Display which comes with a Mini-DisplayPort connector.
The perfect companion for the Radeon HD 5870 SIX
Jawed
Legend
Isn't that exactly what I said?
Hierarchical-Z is a coarse-grained (e.g. quad-level) low-precision (e.g. 12-bit) conservative rejection test and any kind of RBE Z is an acceptance test.
So a short shader (typical for DX8, I guess) is recommended to set Late-Z, which means a conservative hierarchical-Z rejection is possibly made. Acceptance is then performed after shading.
Jawed
I noticed something the critics of dual-slot cooling solutions which the Radeon 5000 family members pictured thus far have failed to notice.
You can't fit 4 display outputs on a single slot backplate and exhaust the heat out of the case.
But why let reason get in the way of a good bashing session?
You can't fit 4 display outputs on a single slot backplate and exhaust the heat out of the case.
But why let reason get in the way of a good bashing session?
Last edited by a moderator:
I honestly gave up a few GPUs ago worrying over single/dual slot, I figure any of the high-end cards from any maker will be dual anymore.
Jawed
Legend
Found it, I keep forgetting that
It's a tile-level rasterisation only. So very cheap in terms of rasterisation, but requires that all vertex shading that affects the position attribute is computed.
Slide 26 says front-end is ~10% of the entire compute effort.
The amount of data in a bin varies, you've described a heavy-weight bin. A flimsy bin with nothing more than triangle IDs would be cheap in a multi-chip solution. This would make the back-end more compute-heavy, which would hide some of the latency associated with NUMA. This trade-off between light/heavy is seen in current games where developers elect either to compute all attributes during vertex shading or leave some of them for computation during pixel shading (these are attributes derived from other attributes, normally) - you can view this as a form of compression of the per-vertex data.
Consumption of vertex data is basically a streaming problem, i.e. quite latency tolerant, if you have some decent buffers. Vertex data, due to the connectivity of triangles, strips, etc., never neatly fits precisely into cache lines, so the best approach is just to read big-ish chunks rather than individual vertices/triangles. So two chips (conventional or Larrabee) consuming from a common stream are going to be slightly more wasteful in this regard - this is similar to the wastages that occur with different vertex orders in PTVC.
But Larrabee can run multiple render states in parallel. So most trivially you can have the two chips working independently. Whether two successive render states are working with the same vertex inputs (e.g. shadow buffer passes, one per light?) or whether they're independent vertex inputs, the wastage is down purely to NUMA effects.
Bin spread should fall if flimsy bins are used, since the tiles can be larger (which reduces bin spread).
Back-end burden would be perfectly spread across both chips. Sure, two chips won't achieve 100% scaling - we aren't expecting that. Even Intel's estimates/simulations for scaling with core count on a single chip aren't linear...
I don't understand how you get double.
I don't understand what you mean by PrimSet distribution. Each PrimSet can run independently on any core. The data each produces is a stream of bins. They consume vertex streams and, if they already exist, render target tiles.
Some scheduler, somewhere, must then assign bin sets to cores. This is not a heavy task. Back-end has to consume the bin and create/update the render target tile. The scheduler isn't delivering bin data to back-end tasked cores.
If these are flimsy bins then I don't see the issue. If these are bins with in-progress render target tiles, then that's a bit more costly. Clearly heavy-weight bins are going to be the mostly costly. There's zero reason to build a multi-chip non-NUMA-aware software pipeline - Intel clearly intends not to build a one-size-fits-all software pipeline. Though I'll happily agree that multi-chip is low priority until single-chip is working really well, apart from anything else because it's harder.
Overall, though, I would expect that a memory-bandwidth:link-bandwidth ratio of X would serve Larrabee better than traditional GPUs. You have a huge amount of programmer freedom with Larrabee to account for the vicissitudes of NUMA.
Jawed
It's a long long latency whichever side of the pixel shader you do it on though, so if the pixel shader is light (both in time and context) then doing it in front might make sense. Either way you are going to have to store data until the Z check is resolved.
Since the pipeline is virtual it's not a huge deal though ... the shaders can simply start doing something else (or rendering to a different part of the screen which has nothing in the pipeline).
Jawed
Legend
Which only intensifies the need for architectural improvements. For what it's worth, doubling the RBEs per unit bus width is doing that.
Thanks, seems reasonable and seems to indicate that drivers haven't changed the balance between the two in a significant way.
Jawed
Jawed
Legend
Except for ATI cards the documentation is quite explicit that early-Z is not recommended for short shaders. I take this to imply that the buffers post-rasterisation/pre-interpolation are too small compared with the buffers post-pixel-shading. OpenGL guy hasn't given a reason, so far.
The pipeline is only virtual in this sense on Larrabee (anything else?). It's a real, single-pixel-shader-at-a-time pipeline on current ATI GPUs, excepting the virtualisation required to share the unified shaders amongst VS/GS/PS (and others).
Jawed
OpenGL guy
Veteran
There are reasons to use late-Z in such cases, you can contact AMD developer relations for more info.
You're certain of this? A close look at the reg specs may give more information.
Broken Hope
Regular
XFX version is being bundled with Dirt 2.
http://www.xfxforce.com/en-us/Features/RadeonHD5870.aspx#1
http://www.xfxforce.com/en-us/Features/RadeonHD5870.aspx#1
Well actually dual link hdmi exists too (since hdmi 1.0) but requires different connector and I don't think a single piece of consumer electronics with such a connector exists
.I'm wondering though does rv8xx (or actually older ones too) support those increased clock rates for hdmi 1.3? Certainly some 30" monitors don't, making hdmi input rather useless.
Also, how do these active DP -> dual link dvi converters work? Are they "true" DP devices so the graphic card output works in display port mode then they just translate to dual link dvi? Only apple really seems to sell them in any quantity. In any case, how do things like hdcp work?
Yes, they have DP recievers and transmitters for the type of output they are going to. Likewise, they will need their own HDPC keys.
Apples may be the only prominent vendor at the moment, but we are working with others and we expect more to become available.
XFX version is being bundled with Dirt 2.
Now that's sexy. Guess all it needed was a paint job
Techpowerup did a primer article from the leaked info and stuff. It's practically the summary of this whole thread pretty nice read though, instead trying to read 3400+ posts from this thread
http://www.techpowerup.com/reviews/AMD/HD_5000_Leaks/
pretty nice read though, instead trying to read 3400+ posts from this thread http://www.techpowerup.com/reviews/AMD/HD_5000_Leaks/
Just too bad I first saw this after 3400+ posts..Techpowerup did a primer article from the leaked info and stuff. It's practically the summary of this whole thread
http://www.techpowerup.com/reviews/AMD/HD_5000_Leaks/
Some independent benchmarks from one lucky XS member:
first verification pic
now some scores,
HD5870 stock - i7 965 stock (3.2GHz)
3DMark06 - 16xAF forced in CCC
22383 3DMarks
SM 2.0 Score 8704
SM 3.0 Score 10655
CPU Score 6282
No AF forced in CCC
22549 3DMarks
DMC 4 1920x1080 8xAA 16xAF
scene 1 162.78
scene 2 123.86
scene 3 221.67
scene 4 118.59
resident evil 5 1920x1080 max details 8xAA
97fps
first verification pic
now some scores,
HD5870 stock - i7 965 stock (3.2GHz)
3DMark06 - 16xAF forced in CCC
22383 3DMarks
SM 2.0 Score 8704
SM 3.0 Score 10655
CPU Score 6282
No AF forced in CCC
22549 3DMarks
DMC 4 1920x1080 8xAA 16xAF
scene 1 162.78
scene 2 123.86
scene 3 221.67
scene 4 118.59
resident evil 5 1920x1080 max details 8xAA
97fps
Shots from a tessellation demo for the new radeons:
http://img193.imageshack.us/my.php?image=00031.png
http://img193.imageshack.us/my.php?image=00030.png
http://img193.imageshack.us/my.php?image=00029j.png
http://img193.imageshack.us/my.php?image=00028.png
http://img193.imageshack.us/my.php?image=00019v.png
http://img193.imageshack.us/my.php?image=00018.png
http://img193.imageshack.us/my.php?image=00017.png
http://img193.imageshack.us/my.php?image=00016.png
http://img193.imageshack.us/my.php?image=00003h.png
http://img193.imageshack.us/my.php?image=00002i.png
http://img193.imageshack.us/my.php?image=00001z.png
http://img193.imageshack.us/my.php?image=00000w.png
http://img193.imageshack.us/my.php?image=00031.png
http://img193.imageshack.us/my.php?image=00030.png
http://img193.imageshack.us/my.php?image=00029j.png
http://img193.imageshack.us/my.php?image=00028.png
http://img193.imageshack.us/my.php?image=00019v.png
http://img193.imageshack.us/my.php?image=00018.png
http://img193.imageshack.us/my.php?image=00017.png
http://img193.imageshack.us/my.php?image=00016.png
http://img193.imageshack.us/my.php?image=00003h.png
http://img193.imageshack.us/my.php?image=00002i.png
http://img193.imageshack.us/my.php?image=00001z.png
http://img193.imageshack.us/my.php?image=00000w.png
Silent_Buddha
Legend
I wonder if Dirt 2 will carry a redistributable Dx11 package?
Also wouldn't it be really cool if ATI did a tesselation demo similar to the old Toy Store one that had way back when? That's still one of the best graphics demo's I've ever seen.
Regards,
SB
Silent_Buddha
Legend
Similar threads
