CPU:
•1-2 Orders of magnitude less drawcalls
•~75% of previous AC, with ~10x objects
GPU:
•20-40% triangles culled (backface + cluster bounds)
•Only small overall gain: <10% of geometry rendering
•30-80% shadow triangles culled
Work in progress:
•More GPU-driven for static objects
•More batch friendly data
what's this mean for us? They made Unity more efficient?
Plan B if Windows 10 adoption fails.
Eh, there's always Vulkan.
Haha, funny joke. I thought the last 10 years of OpenGL development had shown how that plans out.
Anyway, getting back on topic and talking about novel rendering pipelines, I personally found this, quite interesting. It's Media Molecules game "Dreams", where their engine has essentially dropped the normaler rasterizer pipeline and is 100% compute based, with the graphics made up of point clouds.
Yup, that one is pretty awesome too! Great read too, as they go through a bunch of failed prototypes before they get to the final working solution.
NEW DX12 (PC) FEATURES
 ExecuteIndirect
 Asynchronous Compute
 VS RT index (GS bypass)
 Resource management
 Explicit multiadapter
 Tiled resources + bindless
 Conservative raster + ROV
FEATURES IN OTHER APIs
 Custom MSAA patterns
 GPU side dispatch
 SIMD lane swizzles
 Ordered atomics
 SV_Barycentric to PS
 Exposed CSAA/EQAA samples
 Shading language with templates
On the GPU we achieved significantly more effective culling, but this translates to only a small gain overall for the geometry rendering. We also had to move the gpu pipeline to async compute to remove the cost from the many stalls required for dependent compute jobs and compute jobs. For many passes the compute jobs of the gpu pipeline also do not completely fill the gpu, wasting time if not done in parallel with rendering.
In the future use of bindless textures will allow us to further reduce the number of drawcalls significantly. Apart from the CPU benefits this will also help with the problem of increased GPU overdraw due to the unpredictable drawing order of batched meshes. As the number of drawcalls becomes very low, the drawing order will once again approach the order sorted by object center camera distance. With a very low number of drawcalls actual cluster camera distance sorting could become feasible.
As DX12/Vulkan reduces the cost per individual drawcall significantly, the biggest immediate benefit of a GPU-driven rendering pipeline (given the rendering algorithms and data used in ACU) would be reduced. Whether this kind of pipeline provides a benefit under DX12/Vulkan will depend on the data and rendering algorithms that are used going forward.
The next part of the talk will show some of the very interesting possibilities.
---------------------------------
GPU-driven still has*advantages:
* *- With DX12 (especially on PC), the*CPU still doesn't have low latency access to GPU depth buffer -->**CPU cannot cull shadows based on visible pixels.
* *- CPU is still bad at culling 100k+ objects at sub-object granularity (=*more than a million*visibility tests per frustum).
* *- GPU driven culling*is more power efficient. Reduced power usage increases CPU & GPU*clocks -> runs faster.
* *- Reference:*Modified Intel*DirectX 12 asteroids demo with ExecuteIndirect. Runs faster on Intel GPU and has much lower CPU usage.
With more control over async compute we hope to move the non-rendering part of the GPU-driven pipeline into async compute to remove all pipeline bubbles due to many small synchronous compute jobs (e.g. the compute jobs to generate the compute arguments for the next indirect compute job). We do already run other GPU-tasks in parallel during geometry only rendering (shadow, visibility), but do to the very coarse load balancing between async and graphics pipeline, the async compute jobs do not fully utilise the GPU during bubbles in the graphics pipe.
It's an alternative approach to reducing CPU overhead. Instead of trying to push millions of draw calls, your CPU only launches a couple of draw calls- and the GPU handles the rest of the rendering process, doing GPU culling, launching the actual render parts of the pipeline.
To draw an object on the screen, the engine has to issue a draw call to the graphics API (e.g. OpenGL or Direct3D). Draw calls are often expensive, with the graphics API doing significant work for every draw call, causing performance overhead on the CPU side. This is mostly caused by the state changes done between the draw calls (e.g. switching to a different material), which causes expensive validation and translation steps in the graphics driver.
Unity uses static batching to address this. The goal of the static batching is to regroup as many meshes in less buffers to get better performance, rendering giant meshes instead of a lot of small meshes which is inefficient. Unity will only loop on the same resources to render different ranges of these resources. Effectively it executes a series of fast draw calls for each staticcally batched mesh.
There is absolutely nothing new about this. Most game engines allow this and designers do it all the time. It minimizes the number of draw calls and hence 'stalling' of the pipeline, basically giving the GPU much more work to do in a single draw call by making that draw call very large and complex.
What they've done is keep the draw calls down by doing a massive amount of linking up different geometric shapes that might otherwise appear unrelated.
PCPer talks about this too -
This is a single draw call for animating 3 birds in flight.
[/QUOTE]
Do you mean batching? Redlynx's engine only does 2 indirect draw calls for any arbitrary scene. Then they handle scene visibility on the gpu itself. I don't think that's the same thing. Correct me if I'm wrong.
Plan B if Windows 10 adoption fails.
Do you mean batching? Redlynx's engine only does 2 indirect draw calls for any arbitrary scene. Then they handle scene visibility on the gpu itself. I don't think that's the same thing. Correct me if I'm wrong.
I don't know where you got 2 indirect calls for a scene, I think that may be true of a particular *object* if there is only one light source. Multiple light sources cause more draw calls for all objects affected by the light. So if you have say 500 separate polygons and one light source, you got at least 1000 draw calls.
I think their main point was a novel way of applying textures. Normally that's part of the draw call, but the slides indicate are linking up to textures somehow without it being part of the draw call. They also are doing a lot to make sure they aren't issuing draw calls for things that can't be seen on screen.
This has some answers on draw calls :
http://stackoverflow.com/questions/4853856/why-are-draw-calls-expensive
and
http://www.nvidia.com/docs/IO/8228/BatchBatchBatch.pdf
I also wonder what they mean by "other APIs", do they mean Vulkan or the Gameworks/CUDA SDK?