It sounds like a clever engineer at MS is finding a way to make their peak theoretical bandwidth higher than 176GB/s. The actaul hardware didn't change and I doubt they really discovered anything (this is a deterministic system they would know how it behaves before there was silicon). Sounds like part of the PR war IMO.
Xbox One (Durango) Technical hardware investigation
- Thread starter Love_In_Rio
- Start date
- Status
Bidirectional bus? It doesn't make a lot of sense. Peak theoretical hardware limit is bus*clock. Can't get past that. If the bus is bidirectional by design, you'd get double peak BW. The key info in the DF article is 'holes', which means nothing to me.
It does match what Cranky's said, though, that with 133 GB/s realistic BW, plus 68 GB/s DDR3, we get the 200 GB/s of the E3 conference. I just can't see what the hole is and how it gets filled.
Yes, I get that. I'm just taking their claim first based on what DF reported about processing holes. What are those holes ? (assuming it's not a worm hole).
Love_In_Rio
Veteran
They found a loop in the chip that allows two things at the same time?.The first quantum chip?.
Last edited by a moderator:
Anyway, if it's just a "OMG, look it' faster than we thought", devs would be already in the known: they have the beta devkit since March, i'm sure they would be aware if the hardware is faster than the docs tell.
The only plausible meaning of this news is that in they made some change in the production SoC.
The only plausible meaning of this news is that in they made some change in the production SoC.
Love_In_Rio
Veteran
Yeah, 750Mhz.
Apparently there is no suggestion of any downclock. It's still 800MHz for the people making X1 games.
Well, the articles still states that for full read/write operations the BW is 102 GB/s, and states that there are no downclocks.
We now know what was the secret fairy sauce: a magical bus than is directionaly limited to 102 Gb/s, but can transfer at twice the speed if used at the same time for read and write!
Well, or change the doc to reflect the hardware's peak capability better. It reads more like an optimization of sorts instead of pure upgrade. It's also possible that to make it hit that high number, something else needs to give or happen.
Love_In_Rio
Veteran
So 192 is arbitrer?.
Assuming no upgrade or downgrade in h/w, may be...
Worst case scenario is they stop "everything" and pump things through bidirectionally for benchmarking. Best case is for developers to find holes to make this happen in more practical situation ?
That is the only way I can think of for now without h/w upgrade, and relying on DF's "hole" report. But I kinda flipped the "hole" situation around.
May be someone else can think of better ideas.
Edit: I assume no upgrade because they said MS engineers stumbled upon the discovery.
Worst case scenario is they stop "everything" and pump things through bidirectionally for benchmarking. Best case is for developers to find holes to make this happen in more practical situation ?
That is the only way I can think of for now without h/w upgrade, and relying on DF's "hole" report. But I kinda flipped the "hole" situation around.
May be someone else can think of better ideas.
Edit: I assume no upgrade because they said MS engineers stumbled upon the discovery.
According to the Eurogamer article, the hardware can R/W simultaneously, so it can open up new scenarios.
32MB of ESRAM is enough for a full 1080p framebuffer + Z.
As I understand it -Gipsel, sebbbi, etc, help me if I am wrong, please-
the depth buffer should allow, considering the bandwidth is high & the latency is low, all sorts of compute-based post-processes on the framebuffer.If this is in fact the case any IQ drop due to main memory bandwidth and lower compute than PlayStation 4 GPU may be offset by some really stellar post-processing.
Love_In_Rio
Veteran
According to the Eurogamer article, the hardware can R/W simultaneously, so it can open up new scenarios.
32MB of ESRAM is enough for a full 1080p framebuffer + Z.
As I understand it -Gipsel, sebbbi, etc, help me if I am wrong, please-
If this is in fact the case any IQ drop due to main memory bandwidth and lower compute than PlayStation 4 GPU may be offset by some really stellar post-processing.
Accidentally opens many scenarios.Even the downgrade one.This is not serious...
The hole is also described as a processing hole... which isn't something I'd naturally associate with a bus.
As someone mentioned earlier, is it possible that something is hardwired to the ESRAM that can (in specific circumstances) access part of the memory at the same time as the GPU?
The XBone developers telling him this are also telling him that the GPU clock is still 800MHz.
Thats the way it looks. Someone should email richard.
A downdclock is not something you'd want to hide from devs. And it's not clear how they arrive at the theoretical peak for this optimisation.
It gets pretty tiring to see people making fun of an article, and mocking the news when something positive has been said about the Xbox One --it doesn't have to do with you tho.
It's not PR at all, the DF article says at the VERY beginning...
So this doesn't come from a journalist nor a CEO, it's from a certain source, whoever they are.
Shifty has said it pretty clearly -please read first...-.
I read the 192GB/s as the eSRAM only. They mention 88% improvement, 1.88*102GB/s=191.8GB/s.
Now the PR team can use 192GB/s+68GB/s=260GB/s peak. Of course it would be about as dishonest as Major Nelson weblog where he added 256GB/s eDRAM to the system bandwidth of the 360.
If the physical interface is 128 bytes wide at 800 MHz, that would be the bandwidth the ports can provide.
The blending scenario could allow for queuing logic has some kind of forwarding or coalescing capability. Within the length of the read/write queue, detecting a read to a location with a pending write could allow the read to source from the queue and allow the next operation to issue. A small amount of read buffering could also provide a secondary read location within a small window.
Maybe it can also combine contiguous writes, but that might be unnecessary complication since no client can send enough write data to tell the difference.
The GPU's read capability is wider than its write port, so forwarding or coalescing reads in tandem with another access actually have additional data paths that can carry the data.
This brings back my earlier questions as to where in the memory subsystem the eSRAM hooks in.
The blending scenario could allow for queuing logic has some kind of forwarding or coalescing capability. Within the length of the read/write queue, detecting a read to a location with a pending write could allow the read to source from the queue and allow the next operation to issue. A small amount of read buffering could also provide a secondary read location within a small window.
Maybe it can also combine contiguous writes, but that might be unnecessary complication since no client can send enough write data to tell the difference.
The GPU's read capability is wider than its write port, so forwarding or coalescing reads in tandem with another access actually have additional data paths that can carry the data.
This brings back my earlier questions as to where in the memory subsystem the eSRAM hooks in.
- Status
Similar threads
