curl-6 said:
Yeah, they said some time ago that the Wii U's large eDRAM made their new engine possible, and deferred rendering and triple buffering seem the logical culprits. They've also said in the past they use eDRAM as a fast scratchpad for some GPU and CPU work. |
I must add that I am quite surprised of what the developers of shinen are capable eventhought they are a small indie company, they are not just trying to get must of the wii u system taing profit of the big bandwidth and low latency the edram gives, but also they wisely employing a good amount of tricks to keep performance as high as possible like the use of defered rendering, tiled textures and occlussion culling, sll of them reduce the stress in the gpu and give good results if well used; its not just about power draw but also about power-wise use
here is a bit about defered shading
https://hacks.mozilla.org/2014/01/webgl-deferred-shading/
"
Forward Shading
Today, most WebGL engines use forward shading, where lighting is computed in the same pass that geometry is transformed. This makes it difficult to support a large number of dynamic lights and different light types.
This requires a different shader for each material/light-type combination, which adds up. From a performance perspective, each mesh needs to be rendered (vertex transform, rasterization, material part of the fragment shader, etc.) once per light instead of just once. In addition, fragments that ultimately fail the depth test are still shaded, but with early-z and z-cull hardware optimizations and a front-to-back sorting or a z-prepass, this not as bad as the cost for adding lights.
To optimize performance, light sources that have a limited effect are often used. Unlike real-world lights, we allow the light from a point source to travel only a limited distance. However, even if a light’s volume of effect intersects a mesh, it may only affect a small part of the mesh, but the entire mesh is still rendered.
In practice, forward shaders usually try to do as much work as they can in a single pass leading to the need for a complex system of chaining lights together in a single shader. For example:
The biggest drawback is the number of shaders required since a different shader is required for each material/light (not light type) combination. This makes shaders harder to author, increases compile times, usually requires runtime compiling, and increases the number of shaders to sort by. Although meshes are only rendered once, this also has the same performance drawbacks for fragments that fail the depth test as the multi-pass approach.
Deferred Shading
Deferred shading takes a different approach than forward shading by dividing rendering into two passes: the g-buffer pass, which transforms geometry and writes positions, normals, and material properties to textures called the g-buffer, and the light accumulation pass, which performs lighting as a series of screen-space post-processing effects.
This decouples lighting from scene complexity (number of triangles) and only requires one shader per material and per light type. Since lighting takes place in screen-space, fragments failing the z-test are not shaded, essentially bringing the depth complexity down to one. There are also downsides such as its high memory bandwidth usage and making translucency and anti-aliasing difficult.
"
