The move engines can do a little bit more than just move. They can decode and encode while moving. So they can be used to save memory bandwith and memory space. and while doing this.
the memory system is unified. virtually unified. it is one big virtual address space, it is only the software that prevents you from directly accessing the sram via cpu (to prevent memory contention on sram). This is also something a lower level api can provider better access methods etc to maximize sram bandwidth usage.
Also you don't have to copy something into sram or to DDR3 from the sram. the gpu can read from both. e.g. read from ddr3, process it and write the result back to sram if it is frequently needed/written. You can move something into ddr3 if you need the bandwith of the sram is needed for something else, but it is not a must. right now most developers seem to just use the sram for the rendertarget. but that may change in future (not every part of the render-target is needed in the fast memory all the time).
Yes, you wouldn't do a straight copy, you'd do it through a shader. It'll afford you a little more bandwidth than the move engines which combined/or individually max the bus out at 32 GB/s. I believe a shader pulled from DDR3 can provide a greater number than that.
well... did I just start a esram debate again ... sry for that with my last post I meant the sram block that is outside of the 32mb which is ~2-3mb when you measure it's size. I still wanne know what this is used for. But maybe it is just used for video-encoding or anything like that ^^ some multimedia thing nobody needs because "it is a all in one device".
The sram is even devided in 512kbyte chunks
Still pooled into 4x8MB. And also, are you sure that exists as 'esram', what if that is something else entirely.
Digital Foundry: If we look at the ESRAM, the Hot Chips presentation revealed for the first time that you've got four blocks of 8MB areas. How does that work?
yeah, shape is for audio processing, but it isn't very flexible right now and almost not used in games today. It just may need some SDK improvements. It just seems it was not yet ready for launch like many things. Maybe in future it will offload some cpu usage, or just increase the sound quality in any ways.
Sadly, audio is never used, but with respect to the topic of DX12, I don't think it'll add any additional featureset here to the audio side of things.
The flash memory is still a mystery. Well that's not it. the OS has it's own memory somewhere in the 3gb. Suspend like the PC is not used, because the xbox must powered for instant on. Wouldn't be needed if the suspend for flash would be done. but maybe a real suspend mode is coming with future OS updates.
Interesting that it's still unknown/unconfirmed. Regardless though, I don't feel a strong correlation between 8GB NAND flash and DX12.
well they told us in the interview they customized some things. The example was the command processor. so there may be some hardware requirements. Not to make a new feature, but to make the new feature fast enough so it can be effectively used. There is nothing from preventing Sony to also get this feature into there libs, but it may have e.g. a higher cpu-overhead.
Right, like I said earlier, I think X1 has more stuff than the standard GCN1.1. My reasons are stated above, they spent a lot of money to build this device there is probably some thought of future proofing. I mean, they knew what was coming ultimately, there's no doubt, MS wasn't predicting the future when they were collaborating on DX12, they were shaping it. It's not like they didn't do that for Xbox 360. They knew DX10 was coming and they put it into 360. So the question really becomes, what is the focus on DX12, is it more than just a low level driver and usable parallel rendering across multiple cores.
I'm excited at the prospect of seeing more VXGI in games in the future, hopefully there are more surprises to come.
Yes correct whoops.
