• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Xbox One hardware breakdown by ExtremeTech.com after HotChips reveal

You are indeed right, it can be broken down further! The Xbone APU could be 1004 processors total now.

trinity_unbmea9q.png


Again, here are you suggesting some people is counting controllers as proccessors to try to mock MS for counting encoders/decoders as processors. Thing they are.
 

ShapeGSX

Member
dont get the multi-tasking home theater integration about Xbone...i can do most tasks now with ps3. seems like some really pr talk about the wonderful world of xbone media snapping. really dont understand the hype.

If anything Xbone + kinect is but to me a voice enabled logitech harmony remote.

imo, i rather save the console processing power and do my own channel/input switching with my fingers than my voice..., and at least i dont have to turn on a console, turn on the internet modem just to watch tv.

If you are watching TV from your DVR through your XBox One, you will still see game invites pop on screen, and you can swap instantly between a game and the DVR.

I have a Harmony One, and although it works well enough, there is still enough of a pause while swapping activities that I don't usually swap back and forth that often.

Anyway, I'm looking forward to it. :)
 
And one mystery is still unsolved:
05.jpg


What's up with that black arrow between the CPU and eSRAM?

My guess? The ESRAM, like the EDRAM in Intel's new Haswell chips, can use the Xbox One's ESRAM like a cache. But obviously because this isn't your traditional cache, and instead a generic scratchpad, it instead likely means that, as opposed to the CPU sometimes having to get its data from main memory, which is slower, devs can choose to store certain important pieces of data that might otherwise be in the CPU's caches in order to cut down on cache misses in a much larger, and rather similar, piece of memory such as the Xbox One's 32MB of ESRAM.

Between the two 4 core Jaguar clusters, you're dealing with a total of

512KB of L1 Cache (divided evenly between the two 4 core clusters)
and 4MB of L2 cache (also divided evenly between the two clusters)

32MB of ESRAM looks like mighty attractive assistance to that CPU in cases where there's just no more space left inside either of those caches to fit the relevant data.

http://www.realworldtech.com/intel-dram/

A recent presentation from Intel at IDF Beijing indicates that the DRAM actually functions as another level in the memory hierarchy for both the CPU cores and graphics; essentially a bandwidth optimized L4 cache.

Maybe that's what that line implies. Perhaps MS and AMD did something similar to what Intel did with the EDRAM in haswell. it could be any number of things really. As an example, you know how like the PS4 has that onion+ bus that allows it to bypass the GPU's caches? Maybe this is similar to that, but only in reverse. Maybe it's the CPU's cache that's being bypassed with data being fed to it from the ESRAM, which would make it, again, similar to what Intel did with Haswell. Because I think it's interesting that the line starts from above the CPU Cache Coherent Memory Access block. Maybe ESRAM data can be delivered directly into the CPU's registers.

*Snip* I did read it all, however, just don't want my current post looking too long.

A major mistake that people are making with my posts in general is that I've never particularly cared how much stronger the PS4 is, or how much weaker the Xbox One is, and maybe I share a lot of the blame for not making that more clear, but literally my very first post on this forum ever says precisely that. That I don't think it matters how the Xbox One compares or matches up to the PS4, only that I think it's far more important that it's a big enough jump over the Xbox 360, and that Microsoft are providing developers with enough power to make incredible next generation games. When I say things like that, people say "Oh my god, listen that MS PR!!!" "Get the shill!!" etc. When I post Dave Baumann's comment, it isn't to say OMG, look, the Xbox One's graphics performance will far and away be better than a 7790, which means it could threaten the PS4. No, far from it. If, as Dave Baumann says, the Xbox One's graphics subsystem will far and away outstrip even a Radeon 7790 when devs make proper use of the ESRAM, then this also largely applies to the PS4 also, even though it isn't an EDRAM or ESRAM design. If the Xbox One at around 1.2/1.3 TFLOPS can, in dave's view, carry the real potential to outperform a 7790, it means the PS4's GPU will likely far and away outstrip an even stronger AMD GPU when all is said and done.

The general point to many of my posts on this particular subject have not been to say the Xbox One will be stronger or just as strong as the PS4. No... I'm not trying to "close that gap" as some have accused me of doing. It has always been my intent to point out that the Xbox One's graphics performance, despite flawed comparisons to the Radeon 7770, or even to a desktop Radeon 7790, which looks better on paper in many respects, will not only likely end up surprising people, but is likely to outperform either of those two desktop cards in the long run.

In conclusion: I don't care about the comparison to the PS4 and the Xbox One. You don't have to be a genius to see that the PS4 is the noticeably stronger machine. I just like to point out, and I think rightfully so, that I think the Xbox One is going to be a hell of a lot stronger as a gaming system than people are giving it credit for. It won't outclass the PS4, but it will sure as hell still surprise people with what it can do. That's why I take comments from beyond3D from people that have developed games, and are currently developing games when they talk about the potential of the Xbox One, that's why I post Dave Baumann's comment on the Xbox One, and that's why from talking to a friend in first party development for xbox one, and listening to what they have to say about the potential performance implications of low latency esram on the system's performance among other things, I continue to believe that the Xbox One is a pretty damn powerful game console. And after seeing what devs did with 10MB of EDRAM on 360, I will not have anyone telling me that 32MB of even more versatile low latency ESRAM is suddenly "useless," or will hardly make a difference, because it's too small.

The challenge others have is to not assume that just because I'm hopeful and excited to see how the Xbox One performs, that it means I'm somehow doubting the power level of the PS4. To use a DBZ reference, I know full well that the PS4 is Goku, and the Xbox One is Vegeta. Super Saiyan Goku vs Majin Vegeta is the two systems in a multi-platform game. Super Saiyan 3 Goku is the PS4 in an exclusive.
 
Previous post was talking about Xbone aiming for 7790 performance but in reality getting 7700 performance (1.28 TFlops). Gee, where is the Xbone sitting at from Microsoft's own mouth? Right around 1.28 TFlops.

7700 isn't even a model. It is a series, and HD 7790 is a model included in that series. That quote makes no sense.
 

Dunlop

Member
not at 499, internet connection, monthly subs, kinect-is-not-new.

I said it differentiated the XB1, it has features that cannot be replicated on the PS3 or a tablet

I am kind of a bridge: former hardcore gamer migrating to old fart casual. While it is a periah here, my experience is that Kinect is well received in the real word.

Anecdotal of course, but my kids are on MANY sports teams and talking to the parents the 360 with Kinect was the main systems these kids uses and generally loved the whole play vs Kinect functionality.

Now the question is how badly the $100 difference between the XB1 and PS4 will hurt them

The Wii has lost it's favor as the family system and I think MS filled that void. PS4 looks awesome on paper but I think they need to work on their family friendly image for sustained sales. They will both sell like gangbusters for the first 6 months
 

HokieJoe

Member
My guess is, is that any special purpose bits MS has added in part represents an attempt to overcome shortcomings they discovered from their experience with the 360 (see) ; and to optimize engineering vs economics factors. Obvious stuff for sure, but I think it gets lost in some of the discussions here. The unanswered question is whether or not it will pay off.



Again, here are you suggesting some people is counting controllers as proccessors to try to mock MS for counting encoders/decoders as processors. Thing they are.
 
And you wonder why people dislike ToyBroker and take anything he re-types here with a grain of salt.

lol, good one. But are you seriously calling beyond3d's members such as the ones I've quoted, some of which are known game developers, even sony first party, xbox fanboys?
 

Klocker

Member
Christ almighty...the Dave quote again? What are you SenjutsuSage's minion? :X. We've already said it before, but if what Dave said was even close to being true or relevant, it would have been heavily reported on.

seriously that is the most ridiculous logic trying to deflate a comment by a knowledge based technology person that I have ever heard...if it were true it would have been reported in? Omg that is rich... Unreal downplaying of facts and rewriting of perception going on in this now derailed thread
 

KidBeta

Junior Member
My guess? The ESRAM, like the EDRAM in Intel's new Haswell chips, can use the Xbox One's ESRAM like a cache. But obviously because this isn't your traditional cache, and instead a generic scratchpad, it instead likely means that, as opposed to the CPU sometimes having to get its data from main memory, which is slower, devs can choose to store certain important pieces of data that might otherwise be in the CPU's caches in order to cut down on cache misses in a much larger, and rather similar, piece of memory such as the Xbox One's 32MB of ESRAM.

Between the two 4 core Jaguar clusters, you're dealing with a total of

512KB of L1 Cache (divided evenly between the two 4 core clusters)
and 4MB of L2 cache (also divided evenly between the two clusters)

32MB of ESRAM looks like mighty attractive assistance to that CPU in cases where there's just no more space left inside either of those caches to fit the relevant data.

http://www.realworldtech.com/intel-dram/



Maybe that's what that line implies. Perhaps MS and AMD did something similar to what Intel did with the EDRAM in haswell. it could be any number of things really. As an example, you know how like the PS4 has that onion+ bus that allows it to bypass the GPU's caches? Maybe this is similar to that, but only in reverse. Maybe it's the CPU's cache that's being bypassed with data being fed to it from the ESRAM, which would make it, again, similar to what Intel did with Haswell. Because I think it's interesting that the line starts from above the CPU Cache Coherent Memory Access block. Maybe ESRAM data can be delivered directly into the CPU's registers.



A major mistake that people are making with my posts in general is that I've never particularly cared how much stronger the PS4 is, or how much weaker the Xbox One is, and maybe I share a lot of the blame for not making that more clear, but literally my very first post on this forum ever says precisely that. That I don't think it matters how the Xbox One compares or matches up to the PS4, only that I think it's far more important that it's a big enough jump over the Xbox 360, and that Microsoft are providing developers with enough power to make incredible next generation games. When I say things like that, people say "Oh my god, listen that MS PR!!!" "Get the shill!!" etc. When I post Dave Baumann's comment, it isn't to say OMG, look, the Xbox One's graphics performance will far and away be better than a 7790, which means it could threaten the PS4. No, far from it. If, as Dave Baumann says, the Xbox One's graphics subsystem will far and away outstrip even a Radeon 7790 when devs make proper use of the ESRAM, then this also largely applies to the PS4 also, even though it isn't an EDRAM or ESRAM design. If the Xbox One at around 1.2/1.3 TFLOPS can, in dave's view, carry the real potential to outperform a 7790, it means the PS4's GPU will likely far and away outstrip an even stronger AMD GPU when all is said and done.

The general point to many of my posts on this particular subject have not been to say the Xbox One will be stronger or just as strong as the PS4. No... I'm not trying to "close that gap" as some have accused me of doing. It has always been my intent to point out that the Xbox One's graphics performance, despite flawed comparisons to the Radeon 7770, or even to a desktop Radeon 7790, which looks better on paper in many respects, will not only likely end up surprising people, but is likely to outperform either of those two desktop cards in the long run.

In conclusion: I don't care about the comparison to the PS4 and the Xbox One. You don't have to be a genius to see that the PS4 is the noticeably stronger machine. I just like to point out, and I think rightfully so, that I think the Xbox One is going to be a hell of a lot stronger as a gaming system than people are giving it credit for. It won't outclass the PS4, but it will sure as hell still surprise people with what it can do. That's why I take comments from beyond3D from people that have developed games, and are currently developing games when they talk about the potential of the Xbox One, that's why I post Dave Baumann's comment on the Xbox One, and that's why from talking to a friend in first party development for xbox one, and listening to what they have to say about the potential performance implications of low latency esram on the system's performance among other things, I continue to believe that the Xbox One is a pretty damn powerful game console. And after seeing what devs did with 10MB of EDRAM on 360, I will not have anyone telling me that 32MB of even more versatile low latency ESRAM is suddenly "useless," or will hardly make a difference, because it's too small.

The challenge others have is to not assume that just because I'm hopeful and excited to see how the Xbox One performs, that it means I'm somehow doubting the power level of the PS4. To use a DBZ reference, I know full well that the PS4 is Goku, and the Xbox One is Vegeta. Super Saiyan Goku vs Majin Vegeta is the two systems in a multi-platform game. Super Saiyan 3 Goku is the PS4 in an exclusive.

If this was the case there would be a line indicating its bandwidth to the eSRAM, we have also heard that the eSRAM is free from contention, meaning that it is only used by the GPU. To quote vgleaks.

The advantages of ESRAM are lower latency and lack of contention from other memory clients—for instance the CPU, I/O, and display output. Low latency is particularly important for sustaining peak performance of the color blocks (CBs) and depth blocks (DBs).

Aside from this it is pretty obvious its not a memory link, it doesn't look like any of the others, it doesn't have a GB/s rating, nor does it even seem to go to a area that would be able to access it at all.
 
And you wonder why people dislike ToyBroker and take anything he re-types here with a grain of salt.

You know what's hilarious about you?

The way you talk tech like you know what you're talking about...right then and there you shoulda known...since you're the tech-wiz. Or are you only the tech-wiz when it's serving your agenda?

You literally have no idea what you're talking about most of the time, do you?

I'm not trying to be a dick, but I'm also not even CLOSE to the first person to point this out to you.




I'm sorry, I couldn't resist :p
 

ToyBroker

Banned
You know what's hilarious about you?

The way you talk tech like you know what you're talking about...right then and there you shoulda known...since you're the tech-wiz. Or are you only the tech-wiz when it's serving your agenda?

You literally have no idea what you're talking about most of the time, do you?

I'm not trying to be a dick, but I'm also not even CLOSE to the first person to point this out to you.




I'm sorry, I couldn't resist :p

LOL.

I literally have no clue what I'm talking about half the time so I'm just gonna stfu for a while in these tech threads. So I call truce on Senjutusu....BUT NOT YOU GARRET!!!
 
If this was the case there would be a line indicating its bandwidth to the eSRAM, we have also heard that the eSRAM is free from contention, meaning that it is only used by the GPU. To quote vgleaks.



Aside from this it is pretty obvious its not a memory link, it doesn't look like any of the others, it doesn't have a GB/s rating, nor does it even seem to go to a area that would be able to access it at all.

Good point, and something I thought about, too, but is contention for memory bandwidth the same as the developer having the option to pluck pieces of data from ESRAM and feed it directly to the CPU?

I view lack of contention from CPU as the ESRAM basically being protected from having no choice in the matter of dividing up some of its bandwidth, no matter how much that may be, with anything other than the GPU and its specific memory clients. For example, the DDR3 isn't protected in a similar way, and literally has no choice in the matter, because the CPU cores demand bandwidth and have to get it. So could it just be a case that contention in this instance means the ESRAM isn't automatically forced to share anything with the CPU unless the developer wants it to, essentially providing them a bit more control over the system's resources?

LOL.

I literally have no clue what I'm talking about half the time so I'm just gonna stfu for a while in these tech threads. So I call truce on Senjutusu....BUT NOT YOU GARRET!!!

Haha, no hard feelings, man. This is just something we like to do for a fun distraction anyway. I'm sure we can discuss all sorts of things without sounding like we're trying to kill each other lol. Truce :)
 

KidBeta

Junior Member
Good point, and something I thought about, too, but is contention for memory bandwidth the same as the developer having the option to pluck pieces of data from ESRAM and feed it directly to the CPU?

I view lack of contention from CPU as the ESRAM basically being protected from having no choice in the matter of dividing up some of its bandwidth, no matter how much that may be, with anything other than the GPU and its specific memory clients. For example, the DDR3 isn't protected in a similar way, and literally has no choice in the matter, because the CPU cores demand bandwidth and have to get it. So could it just be a case that contention in this instance means the ESRAM isn't automatically forced to share anything with the CPU unless the developer wants it to, essentially providing them a bit more control over the system's resources?

I can't see how that would work really, it would appear to me that the coherent bandwidth is there for the same reasons it is in the PS4, that is to share data to the main shared pool (the DDR3) in a coherent manner, not to store data for the CPU to use.

A lot, and I mean lot of the stuff on vgleaks strongly suggests that the eSRAM is only to be accessed by the GPU,
 

ElTorro

I wanted to dominate the living room. Then I took an ESRAM in the knee.
A lot, and I mean lot of the stuff on vgleaks strongly suggests that the eSRAM is only to be accessed by the GPU,

Seriously, I would be really surprised if it has any other prime purpose other than holding render targets. It's not comparable to the EDRAM in Haswell which explicitly is a shared cache.
 
I can't see how that would work really, it would appear to me that the coherent bandwidth is there for the same reasons it is in the PS4, that is to share data to the main shared pool (the DDR3) in a coherent manner, not to store data for the CPU to use.

A lot, and I mean lot of the stuff on vgleaks strongly suggests that the eSRAM is only to be accessed by the GPU,

Well, here's where I think the vgleaks info might be dated and wrong in some instances (big assumption, I know). Why would a coherent bandwidth pathway be going into the Host Guest GPU MMU if the coherent bandwidth stuff was just strictly for the DRAM?

All those blue arrows mean that's coherent bandwidth, and the yellowish ones suggest non-coherent access. As you can see, the DRAM has absolutely no need at all to go through the GPU MMU to achieve coherence with the CPU's cache, as it has a more direct route, but the ESRAM, on the other hand, does not have a direct route to coherency. It passes through the GPU MMU.

If ESRAM data is being passed into that GPU MMU as the diagram clearly suggests, then surely the data that passes out of that MMU up to the CPU cache through that blue coherent pathway couldn't possibly just be data that emanates from the pool of DDR3. It clearly also has to be coming from the ESRAM as well. Or, to be more precise, the vgleaks info likely isn't incorrect about lack of contention. It's just leaving out key details that would tell us that this shouldn't be confused to mean that the CPU has no way of accessing ESRAM data or bandwidth. At least that's what I think.
 

KidBeta

Junior Member
Well, here's where I think the vgleaks info might be dated and wrong in some instances (big assumption, I know). Why would a coherent bandwidth pathway be going into the Host Guest GPU MMU if the coherent bandwidth stuff was just strictly for the DRAM?

All those blue arrows mean that's coherent bandwidth, and the yellowish ones suggest non-coherent access. As you can see, the DRAM has absolutely no need at all to go through the GPU MMU to achieve coherence with the CPU's cache, as it has a more direct route, but the ESRAM, on the other hand, does not have a direct route to coherency. It passes through the GPU MMU.

If ESRAM data is being passed into that GPU MMU as the diagram clearly suggests, then surely the data that passes out of that MMU up to the CPU cache through that blue coherent pathway couldn't possibly just be data that emanates from the pool of DDR3. It clearly also has to be coming from the ESRAM as well. Or, to be more precise, the vgleaks info likely isn't incorrect about lack of contention. It's just leaving out key details that would tell us that this shouldn't be confused to mean that the CPU has no way of accessing ESRAM data or bandwidth. At least that's what I think.

Because the CPU needs to be able to be coherent with the GPU's page tables and Cache hence the need for coherent access.

The access to the cache would quite easily be something that just snoops the cache, and reads values back you don't have to be able to write to it.
 

astraycat

Member
Only two more months of this..

As if. Unless NDAs about the hardware go up in smoke when the console releases (they don't) we're going to speculating for years still!

On another note, this thread seems to have really devolved since I went to bed. What happened?
 

Klocker

Member
As if. Unless NDAs about the hardware go up in smoke when the console releases (they don't) we're going to speculating for years still!
p?

Exactly it was almost two years post release before joker came forward and let us know how powerful the edram and xenos were on the 360 compared to ps3 and its complexities of using spus to match power of xenos

Up until that "leak" the misperception of cell dominating all was still firmly in place and denials and excuses for lower quality 3rd party games were rampant.

Unless someone gets vocal we will only have df comparisons and occasional hints to determine how it really is going to play out



On another note, this thread seems to have really devolved since I went to bed. What happened?


An article suggesting the xbones cpu is most likely clocked at 1.9ghz
 
Because the CPU needs to be able to be coherent with the GPU's page tables and Cache hence the need for coherent access.

The access to the cache would quite easily be something that just snoops the cache, and reads values back you don't have to be able to write to it.

Interesting, but I can't shake the feeling that they wouldn't have represented it in such a way if that were the case. They represented that coherent pathway from the GPU MMU as a data pathway, suggesting writing and reading should be possible.

After all, that Host Guest MMU, utilizing the ESRAM's bandwidth, is precisely the way in which the move engines pass data back and forth between the ESRAM and DRAM. That same MMU is also exactly how non-coherent read and write access is achieved for both the DRAM and ESRAM (yellow arrows). So already that's two specific ways in which the MMU helps facilitate data management throughout the system, and between the two pools of memory.

So I don't see why it would suddenly be incapable of managing a third way, which is coherent access between the ESRAM and the CPU with the MMU facilitating the entire thing. The diagram implies that that's what's happening. I also think I just now realized what the thin black line means. Because it starts up top from the blue line, indicating cpu cache coherent memory access, I think what it means to suggest is that there is some kind of cache bypass occurring, but that it's sharing the same 30GB/s bus, but likely operating at a slower speed. Or maybe there's no cache bypass at all, and it's simply just a slower coherent bus from the CPU Cache to the ESRAM.

This comes down to the capabilities of that MMU, and I'm starting to think that's where those leftover MB of on chip storage that MS mentioned are located. An interview where Microsoft explains this stuff would be awesome.
 
lol, good one. But are you seriously calling beyond3d's members such as the ones I've quoted, some of which are known game developers, even sony first party, xbox fanboys?

No I believe he was calling B3D a xbox fanboy haven, which would be correct, as the site has turned into total shit over the years. Sad to see such a great site in the past devolve into such useless shit. Used to be my favorite place for graphics tech talk.
 

KidBeta

Junior Member
Interesting, but I can't shake the feeling that they wouldn't have represented it in such a way if that were the case. They represented that coherent pathway from the GPU MMU as a data pathway, suggesting writing and reading should be possible.

After all, that Host Guest MMU, utilizing the ESRAM's bandwidth, is precisely the way in which the move engines pass data back and forth between the ESRAM and DRAM. That same MMU is also exactly how non-coherent read and write access is achieved for both the DRAM and ESRAM (yellow arrows). So already that's two specific ways in which the MMU helps facilitate data management throughout the system, and between the two pools of memory.

So I don't see why it would suddenly be incapable of managing a third way, which is coherent access between the ESRAM and the CPU with the MMU facilitating the entire thing. The diagram implies that that's what's happening. I also think I just now realized what the thin black line means. Because it starts up top from the blue line, indicating cpu cache coherent memory access, I think what it means to suggest is that there is some kind of cache bypass occurring, but that it's sharing the same 30GB/s bus, but likely operating at a slower speed. Or maybe there's no cache bypass at all, and it's simply just a slower coherent bus from the CPU Cache to the ESRAM.

This comes down to the capabilities of that MMU, and I'm starting to think that's where those leftover MB of on chip storage that MS mentioned are located. An interview where Microsoft explains this stuff would be awesome.

Its the same as the bus in the PS4, which snoops the L2 caches to keep coherency. Its represented as practically the exact same thing just a bit faster.

It seem to me that the CPU cannot touch the eSRAM at all, and for values to be written into a cache they have to be first read by the memory controller, and if the CPU's memory controller cannot read the values from the eSRAM then it cannot have the eSRAM values in its cache, its as simple as that.

A programmer never explicitly reads or writes from a cache it is all controlled by hardware behind the scenes.
 

Klocker

Member
Which, sadly, can be already considered debunked.

well technically it is not a rumor as much as a technical opinion based on information they gained at hotchips and some extrapolation (I believe it is actually supposed to be 1.88 ghz)

the writer is just doing what we all here are doing... estimating, guessing and extrapolating based on some incomplete information

so I guess we will know more when/if MS decides to share.... right now I think they are being very secretive of their design and will share more eventually so we are all guessing at some of this stuff.. even you tech gurus who are knowledgeable and I respect your opinion


I will just wait for more info before deciding what is fact
 

ElTorro

I wanted to dominate the living room. Then I took an ESRAM in the knee.
I will just wait for more info before deciding what is fact

If the authors formula were valid and there really is a fixed ratio between the two numbers, the leaked documents could not have stated a CPU clock of 1,6Ghz and a bandwidth of 30GB/s at the same time. But they do. That is a logical necessity free from technological conjecture. Since the leaked documents have been spot-on on every detail, the evidence against the author's idea is as conclusive as it gets.

Do you have a link or anything explaining why? I'm no good with technical things.

The pages in this thread after the link was posted. I also wrote down the formula that the author used for his calculation.
 
No I believe he was calling B3D a xbox fanboy haven, which would be correct, as the site has turned into total shit over the years. Sad to see such a great site in the past devolve into such useless shit. Used to be my favorite place for graphics tech talk.

I disagree completely, and I'll just leave it at that. :)

Its the same as the bus in the PS4, which snoops the L2 caches to keep coherency. Its represented as practically the exact same thing just a bit faster.

It seem to me that the CPU cannot touch the eSRAM at all, and for values to be written into a cache they have to be first read by the memory controller, and if the CPU's memory controller cannot read the values from the eSRAM then it cannot have the eSRAM values in its cache, its as simple as that.

A programmer never explicitly reads or writes from a cache it is all controlled by hardware behind the scenes.

Does it technically even need to be able to touch ESRAM directly if the data that's present in ESRAM is still able to make it's way to the CPU utilizing that Host Guest GPU MMU? Keep in mind, that ESRAM is likely very closely coupled with the GPU, so if the GPU in anyway is able to pass information to the CPU, then surely that means data which was present in ESRAM can be handled by the CPU without first having to be present inside main ram.

And what about being able to pass pointers between the CPU and GPU?
 
Top Bottom