Xbox One (Durango) Technical hardware investigation
- Thread starter Love_In_Rio
- Start date
- Status
because the CPU has MS own customizations? and probably a higher clock speed is part of that? i remember correctly one of the guys that was right about the GPU upclock said that he heard from some of his sources that the CPU wasn't 1.6GHz.
Is this a valid assumption?
I don't really know anything about Jaguar to know if this is true. Is it true that the north bridge always runs at half the clock of the CPU (Assuming the CPU clock multiplier is 2)? How does the 30GBps coherence link to the DRAM controller suggest they are sticking with a half-clock speed northbridge?
I dont know either, so here's my guess ... That might just be the "common sense" of having semi-synchronous clocks requires far less headaches than purely asynchronous clocks.
I must be missing something here because as far as I can see the CPU has only 1 connection to memory and that's a 30GB/s pipe. Were would additional bandwidth come from if that connection was fully saturated?
The 300% calculation being off aside, I'm with SlimJim on this that is was a stupid statement for the article to make. Comparing the bandwidth of a memory pool shared between CPU and GPU to one dedicated to a CPU is always a pretty short sighted thing to do.
Well, I can see assuming the northbridge is half the clock of the CPU, if that is the norm for that CPU, but I don't know how you get from a 30GB/s coherency link to a 940MHz northbridge. There's some math that I'm missing in there.
Maybe the hint from this earlier part is what I'm not understanding.
Sorry, the bus width from the MMU is 256 bits wide, which matches the bus width to DRAM? And that hints at a half-rate northbridge because ...
I think the calculation he's doing is: 256-bit DDR bus * 940 Mhz / 8 ~ 30 GB/sec.
Never mind. I get it. I'm an idiot.
256bit bus to DRAM from DRAM controller. 30 GB/s from MMU to DRAM controller on a 256bit bus is 938 MHz. Multiply by 2 and you get your clock speed.
They are assuming a clock multiplier so the clocks are still synchronous, rather than being some weird asynchronous design between the MMU and DRAM controller, which is inline with Jaguar.
So the GPU and CPU/northbridge have different clocks? I don't know ...
256bit bus to DRAM from DRAM controller. 30 GB/s from MMU to DRAM controller on a 256bit bus is 938 MHz. Multiply by 2 and you get your clock speed.
They are assuming a clock multiplier so the clocks are still synchronous, rather than being some weird asynchronous design between the MMU and DRAM controller, which is inline with Jaguar.
So the GPU and CPU/northbridge have different clocks? I don't know ...
ProjectNatalFan
Newcomer
So is the 1.9 cpu speed claim incorrect. The guys at neogaf says it debunked. Who should I trust, figured I give you guys a shot at answering the question because you guys blow neogaf away in knowledge
It seems all AMD APU's have asynchronous clocks for the GPU and CPU. If they were synchronous, then the CPU would probably be 1.7GHz as it would be 2X the GPU.
As no one has published anything official, no one without first hand knowledge knows.
The original Vgleaks memory overview shows a 30GB/s coherent link between the northbridge and the GPU, and that was at 800MHz/1.6Ghz.
http://www.vgleaks.com/durango-memory-system-overview/
http://www.vgleaks.com/durango-memory-system-overview/
Yeah, that's the math they are working with.
As for what the real clocks are, there's so many choices to roll with. Perhaps the CPU is 1706 Mhz to make it an even multiple of 2 times the GPU (853Mhz) speed. Or does it make more sense to be some multiple of the DRAM bandwidth (938Mhz for 30 GBps)?
ProjectNatalFan
Newcomer
Sounds like we will never know lol, would it even be a big deal if it was indeed 1.9?
This is a technical investigation thread. "Big Deal" doesn't enter into it; we only care about the raw facts without any connotations or concerns for what that 'means'.
ProjectNatalFan
Newcomer
Well in performance I meant, which I think pertains to the consoles technology. Why even comment if you arent going to even try and answer my question at hand. Oh I see the uber troll lol ok
And on that note, the original vgleaks reveal shows 30 GB/s coherent bus between the northbridge and the GPU memory system. That was back when it was an 800Mhz clock for the GPU and a 800 MHz/1.6 GHz clock for the CPU. So we now know the GPU clock has received a slight bump (853 MHz). If that was the clock for that link, you'd assume the spec would be updated, but maybe it was such a marginal increase they didn't bother. From the other side, if you assume they use the clock for the CPU, then following their logic it could lead you to believe that the clock is now 938 MHz ... but once again the link showed up as 30 GB/s at 800Mhz, so why wouldn't it be updated? Surely that would be a big enough bump to warrant an update to the spec. Or maybe there are three clocks, one for the GPU (853 MHz), one for the CPU and one for the northbridge? I have no idea. I'm inclined to believe it's the clock for the GPU and they didn't bother updating the spec. I don't know what math gets you from 853 MHz to 30 GB/s. No matter what, I think that link is either the same as it was before, or it has been increased so marginally that they didn't bother updating the spec.
The DRAM controller isn't running at 938MHz in their rumour. The MMU on the CPU is. This would be the same as before with the CPU and DRAM clocks not matching. Same is true for PS4, I believe.
Lay person here.
But how can you generate a cpu clock from dram bandwidth? From my reading of AMD docs older apus have less bandwidth to cacheable off chip dram in comparison to bandwidth over the garlic bus. The reasons given is that there is no coherency and the memory allocated to garlic is interleaved.
On old fusion apus, the cpu actually has almost 2X the write bandwidth to the frame buffer then the gpu's read and write bandwidth to cacheable memory. In certain situations the cpu can write just as fast to the framebuffer as it can to cacheable memory. Reads on the other hand are atrocious outside of accesses to cacheable memory.
But how can you generate a cpu clock from dram bandwidth? From my reading of AMD docs older apus have less bandwidth to cacheable off chip dram in comparison to bandwidth over the garlic bus. The reasons given is that there is no coherency and the memory allocated to garlic is interleaved.
On old fusion apus, the cpu actually has almost 2X the write bandwidth to the frame buffer then the gpu's read and write bandwidth to cacheable memory. In certain situations the cpu can write just as fast to the framebuffer as it can to cacheable memory. Reads on the other hand are atrocious outside of accesses to cacheable memory.
I see his math now, but I'm not sure if the logic in the next paragraph follows. It seems like most of the APU components have independent clocks, if you start making them dependent you lose the ability to tune the various cock rates for TDP or performance.
Like Scott said, the 30GB/s and 1.6Ghz numbers are from way back - if correct they imply the clocks are chosen independently.
Like Scott said, the 30GB/s and 1.6Ghz numbers are from way back - if correct they imply the clocks are chosen independently.
- Status
Similar threads
