On the other hand ATI could focus on improving what was there since they already did DP and scatter before ... lets just wait for some benchmarks.
AMD: R7xx Speculation
- Thread starter Unknown Soldier
- Start date
- Status
Jawed
Legend
The patent document seems to imply that the output from these disparate units can be returned to the "cluster" (register file, presumably) - i.e. the staging is "real".That's called marketing...
Haven't a clue who he is.
Even G70 doesn't use the same hardware for vertex data fetches as for texture filtering, does it?
Kinda disappointed you guys haven't wheedled this stuff out...
Until it's benchmarked we won't know the practicalities - clearly total throughput is up for both point and filtered sampling.Yes, it seems they finally decided they could no longer afford to have an incredibly inefficient TMU architecture that made neither theoretical nor practical sense. Shock, horror?
Yeah, sadly at least some of the 9800GTX 16xAF/4xAA benchmarks are blighted by the card apparently running out of memory, so the comparisons with HD4850 are unreliable.
Double-precision was already there in RV670, so that particular aspect shouldn't have changed...
I am intrigued by the idea of 10 SIMDs though - that's quite a lot of control overhead in comparison with 4 SIMDs.
Jawed
leoneazzurro
Regular
I was just assuming the same "horizontal" arrangement we saw in R6xx
If each SIMD gets a dedicated TU ("vertical" - though it's horizontal on this diagram if the SIMDs are now read as rotated 90 degrees) then that's a bit of a change - though in terms of cache I guess the effect of the change is very limited because L1 is basically only big enough for a small region of texels and any one texel will find itself in multiple L1s anyway, whether it's a horizontal or vertical mapping from SIMDs to TUs.
Jawed
It seems to me that the "global data share" could be like a shared link where all SIMD can access in a fast way data in the other SIMD (and access other TMUblocks linked to other SIMDs). that is, it's the "vertical" link between the SIMDs where the "horizontal" link is among shaders in a SIMD and the dedicated TMU block.
Is it possible?
it was on this site that TSMC is skipping 45nm and heading directly towards 40nm (presumably in H2 2009)And by that time comes RV770 in 40nm, and them we will see who catch who
40nm is the half node of 45nm witch is a new process node. It decrease dramatically die-size.
Mintmaster
Veteran
I wasn't implying anything so elaborate. Just talking about the strategy of making units much smaller at the cost of some efficiency/functionality.
Anarchist4000
Veteran
http://www.qimonda-news.com/download/Qimonda_GDDR5_whitepaper.pdf
Page 7.
That does make a lot of sense though. Each GPU would only have half the bandwidth to each memory chip but with twice as many chips all things are equal. Routing on the PCB I see being an utter nightmare. Getting traces around the second GPU and attached to its memory should be interesting.
You'd have to imagine one of the IHVs requesting a spec like that for it to get included in GDDR5. Since Nvidia likes GDDR3 and is making GPUs roughly 1 Kardashian in size I'd think it's obvious who would have asked for it.
The only interconnect would be the control bus. That and some link or partitioning between the schedulers would make a little sense.
Page 7.
That does make a lot of sense though. Each GPU would only have half the bandwidth to each memory chip but with twice as many chips all things are equal. Routing on the PCB I see being an utter nightmare. Getting traces around the second GPU and attached to its memory should be interesting.
You'd have to imagine one of the IHVs requesting a spec like that for it to get included in GDDR5. Since Nvidia likes GDDR3 and is making GPUs roughly 1 Kardashian in size I'd think it's obvious who would have asked for it.
The only interconnect would be the control bus. That and some link or partitioning between the schedulers would make a little sense.
Anarchist4000
Veteran
After further reading it's not quite what I thought.
Clamshell would cut the data bus in half allowing the possibility of two GPUs connected to each chip. What I'm still digging for is if there is any control logic that determines which half of the data bus gets used. Then they could alternate between controllers every other clock etc. If that was the case they'd just have to work out timing and sharing of the control bus.
Clamshell would cut the data bus in half allowing the possibility of two GPUs connected to each chip. What I'm still digging for is if there is any control logic that determines which half of the data bus gets used. Then they could alternate between controllers every other clock etc. If that was the case they'd just have to work out timing and sharing of the control bus.
The data bus is point to point, you can't just bodge an extra couple of 10s of cm of trace to another GPU on those DRAMs data pins and hope it will still run at 4 GHz.
Anyway, there is no real point to doing it like that even if you could. You are still losing bandwidth that way ... if you are going to lose bandwidth anyway you could just directly connect one partition of the memory interface on both GPUs, without a DRAM in between.
Anyway, there is no real point to doing it like that even if you could. You are still losing bandwidth that way ... if you are going to lose bandwidth anyway you could just directly connect one partition of the memory interface on both GPUs, without a DRAM in between.
Last edited by a moderator:
Anarchist4000
Veteran
After going through a little reading the buses can be tri-stated so the point-to-point might not be necessary. The question is how much it affects performance. I'd agree this is pushing things a bit but it's a possible option.
My original idea was that you'd have twice the effective bandwidth but available only half the time as it alternated between controllers. Also there is a mirror option but that appears to flip all the pins. Not just the data pins.
Thought this was intertesting:
http://www.extremetech.com/article2/0,2845,2320134,00.aspJason Cross said:
Anarchist4000
Veteran
My guess would be some sort of global cache for inter-thread communication.
I don't suppose anyone has done a pin count on RV770? For a unified memory architecture I'd assume there has to be some form of high speed interconnect and an abundance, or lack thereof, might give an idea on just what they're doing.
I don't suppose anyone has done a pin count on RV770? For a unified memory architecture I'd assume there has to be some form of high speed interconnect and an abundance, or lack thereof, might give an idea on just what they're doing.
Jawed
Legend
If we knew what the Local Data Share is, maybe we could make a decent guess.
I'm thinking that LDS might be the name for the per SIMD register file.
But GDS is placed alongside texture caches, which implies it's texture-data related. Hell it might be nothing more than memory used to hold addresses or filtering coefficients or something, stuff that's been computed but needs to be kept around for later usage.
If that's the case then LDS might just be data that's specific to a batch for the purposes of texturing or vertex data fetching.
Maybe related to texture arrays and cubemap arrays?
Jawed
Does that picture come from AMD?
It list 40TMU, but by tests so far HD 4850 looks to have 32TMU.
So True/Fake?
What's test?
If it is GPUz, the test will rely on database. So at this point, I think we may need to wait until the launch date to be confirmed all the info about the RV770. It will not be any longer to wait
This round, AMD/ATi do playing a good game on keeping infomation well.
Perlin Noise
Ummm... Isn't Perlin Noise a shader intensive bench?
- Status
Similar threads
