Machiavellian said:
Not sure if you got the point. I am using the ESRAM as an example not how well it works but instead how it works. MS engineers quote a theoretical peak throughput of 204gb/s. Developers can only reach that speed if they are reading and writing to the ESRAM at the same time. Developers have made statements that it's very rare when such situations occur or even if they might occur depending on the game.
The scenario is the same for GPGPU. Being able to do GPU and GPGPU at the same time will depend on the game and the scenarios it can be leverage. For the cost of development even if you have those scenarios it might not net real word difference or it might be off the chain. Until developers actually invest in the time its really up in the air if this will make a difference in games.
|
I think a lot here are confusing how compute can work on the PS4.
The two key things about PS4 compute is that (1) you have 64 compuete lanes (basically you can do more compute tasks in any given amount of time) And (2)asynchronus (huma) compute tech (which basically means that the PS4 unlike the XB1 and PC GPUs up until some released by amd this year has a dediacted 20GB/s bus that communicates directly with the system memory and bypasses the L1 and L2 cahche for GPGPU compute). The second point is NOT common and is nothing taht PCs have been doing cause up until the new R9 series AMD GPUs, such tech (HUMA) didn't even exist in the PC space.
Now onto how it works.
First of, yes, using compute means that you will have to do less typical GPU tasks cause it runs on the same GPU pipeline. But thats just half the story. There are two ways that compute can be used.
- render pipeline assisted compute. In this case you would be using just a little bit of the available 64 compute lanes and thus a little of the GPU to handle tasks that would in turn boost the overall yeild and performance of the GPU. In an example Cerny gave;
say you are running a game that is extremly geometry heavy on the GPU. You can input code that makes a compute pass on the render pipeline that will identify all the front facing polygons(the ones that the gamer can see) of all geometry objects in the scene and the GPU will then only render those polygons and ommit rendering the rest of them even though its getting the complete geometry render instruction set from the CPU. This way it would be possible to render 3-5 times(not sure how much more but basically more) more polygons than your engine would have typically handled or the GPU will spend less time carrying out that specific task giving it more frame time for other tasks.
This could be used in more elaborate ways like marking out certain objects in a scene for AA passes. The small amount of the GPU used to pick out certain aspects in a frame that would'not need an AA pass/shadow detail.....etc will end up freeing up GPU power to be used to do more than it otherwise would have been able to do or basically something else.
- Idle time compute. Contrary to what some may think, ALL of the GPU is not active 100% of the time all the time. There are times when only anywhere between 60-80% of the GPU is being used. Now to put this in perspective you need to understand exactly what is being referred to here.
Take a game running at 30fps. The CPU/GPU basically has 33ms to render each individual frame. That doesn't mean that the GPU spent 33ms rendering the frame. Don't forget the GPU is just one part of the equation. It had to wait for the updated scene render instruction from the CPU. So for those 33ms, the GPU could very well be idle for anything between 10ms-20ms. That idle time could be used for GPU compute and and take some of the work load off the CPU. Thus letting the CPU finish its work faster and cutting down the GPU idle time from 10-20ms to say 5-10ms. Things like this is how compute on the PS4 can assist the CPu which in turn can lead to either higher or more stable framerates in games. Or just more physics/AI/lighting? calculations all around.
(if you understand this point then you will also understnd why what ubisoft said about the CPU load being responsible for why AC:Unity runs at 900p on both consoles. thats just bullshit. A CPU load just measn that the GPU has less time to do its thing, that is more likely to affect framerate than anything else because of how GPUs work. This is where it gets interesting. IThe only way what ubisoft are saying is true is if the XB1 CPU is better than the PS4s, or that the game is better optimized for the XB1 [which brings us back to the whole parity nonsense]. Its interesting cause if say the CPU heavy load takes 25ms to complete its task for the next frame then passes off the render instructions to the GPU, then theoretically limiting the resolution means that they wanted to give the GPU less work to do so it spit outs the frame on time still hitting that 33ms limit. But this is where there is a problem with the story. If the GPUs have only 8ms to complete its task and the XB1 completes that with a 900p frame, what happend to the 40% more GPU that the PS4 has? The PS4 should be able to complete the exact same task 40% faster than the XB1. So if the time is constant, then it means they could have simply allowed the PS4 do more work and it would have still met that render time limit. Unless of course they want you to believe that the XB1 CPU did completed its much much much faster than the PS4s CPU and that way the PS4s more powerful GPU had less time to render the frame than the XB1 so the extra power of the PS4 went to still mathcing the XB1. Which simply isn't the case)
I hope that clears it up, its not ok GPU is doing compuet so everything must suffer type thing. A lot of work was put into the PS4 architecture to make this assited GPGPU stuff possible and effective, and there is a reason why a lot of devs are saying its going to be a big deal down the road. But everything I just explained here wuld take more work to do, will require that the game code is writen specifically to take advantage of stuff like this. Thats why Cerny doesn't expect them to be using it for another 2-3 years.
I could explain the whole ESRAM thing too... and how the whole 204GB/s two way bandwith is just BS but that will make this post much longer than it is. But i would put it this way. Realistically, you will never need to read and write data to memory simultaneously, especially when the memory in question is used to store the frame buffer. When data getsinto the frame buffer, the next stop is your display. And then the next frame gets loaded into the frame buffer. If reading and writing simultaneously was such a big deal, why does any one think MS is making such a big deal about new APIs in their SDKs allowing devs to tile date in ESRAM? Also remmebr that the CPU doesn not have access to ESRAM.
