Grease Pencil: Optimize Drawing Engine #57829

New Issue

Antonio Vazquez · 2018-11-14T16:19:23+01:00

Antonio Vazquez commented

2018-11-14 16:19:23 +01:00

The current implementation of the Grease Pencil drawing engine works, but some areas are very inefficient, so need some changes to improve the FPS.

Analysis done by @WilliamReynish

I made a test with about 20 GP objects, which draws at around 1-2 fps.

Then I made the exact same objects as normal meshes with the exact same # of points. Now I can have 20.000 objects on the screen and play at 24 fps. So there is something going on with GP objects that makes them several orders of magnitude slower than 3D meshes, in a way that seems like something must be wrong. A mesh cannot surely be more than 1000 times faster with the exact same complexity and no animation?

Analysis done by @antoniov

I’m running tests with profile tools and I have seen the main problem is in 3 areas.

Create Shading groups
Cleaning Batch data (GPU_BATCH_DISCARD_SAFE)
Drawing hundreds of shading groups (I mean, pass)

I thought the problem was calculate the geometry but this is not as big as the time used by the topics above.

The problem is GP object creates a shading group for each stroke, so there are a lot of shading groups. Each shading group has its own uniforms because they can be different. We cannot use the z-depth because the first mandatory request is to keep 2D layer priority over z-depth. I mean, last stroke drawn is on top (the z-depth is not important). I remember trying to use a single shading group and hack the z-depth to get the right order, but this solution did not work and the result was very bad.

Other problem is each shading group has its own GPUBatch data, so you have hundreds of small batches instead of a big one, so the clear is very heavy too.

Finally, when you draw the pass, the CPU has to send a lot of shading groups to the GPU instead to send a big one.

About GPU, the multisample and other GPU stuffs reduce speed, but they are not the main problem so we could improve later, but now the difference between on/off is maybe 2 or 3 fps, but use a lot of objects is maybe 40 fps.

Possible solutions (original written by @fclem)

From what I can see you don't use any shader variations, so you can put all the stroke geom into one batch. Just put all geom in it and keep start index and count. With this you can just make calls using DRW_shgroup_call_range_add() with the order you want (using the first and last index). This will only make the VAO change if you draw a fill stroke or change object. This fixes point 1.
With some draw manager improvement (from me) you could even get rid of all the per stroke shgroup if you put every stroke uniform into UBOs and use the draw index to fetch the uniform value. This is how drawing lots of different meshes is done efficiently in vulkan/modern opengl. This would be even faster with the right opengl calls. This fixes point 2.
The next bottleneck then is the multisample blitting. Lots of possible saving here, ordered from simpler to harder:
Manually resolve the area that has been drawn by the layer's stroke. You can do that in two different ways. First is to use GL_SCISSORS, second is to draw a quad with the right size. This does however means that you have to compute the BBox of each object's layer. Only resolve when next layer will overlap the previous. You can use the aforementioned BBox for that. Though I don't think this will have a lot of benefit since it will only skip maybe once per object (I'm not sure).
** Really complex but may worth the assle: draw each layer into a portion of the offscreen buffer and blit back using the techniques above only when the buffer is full. This would be much faster for small objects but not really if all layers fills the screen since it would just be equivalent to what we have now. Doing this also means keeping track of where the layer areas are and do some sort of naive realtime 2D packing. But this should fix 3 in most common cases.

The current implementation of the Grease Pencil drawing engine works, but some areas are very inefficient, so need some changes to improve the FPS. **Analysis done by** @WilliamReynish I made a test with about 20 GP objects, which draws at around 1-2 fps. Then I made the exact same objects as normal meshes with the exact same # of points. Now I can have 20.000 objects on the screen and play at 24 fps. So there is something going on with GP objects that makes them several orders of magnitude slower than 3D meshes, in a way that seems like something must be wrong. A mesh cannot surely be more than 1000 times faster with the exact same complexity and no animation? **Analysis done by** @antoniov I’m running tests with profile tools and I have seen the main problem is in 3 areas. 1. Create Shading groups 2. Cleaning Batch data (GPU_BATCH_DISCARD_SAFE) 3. Drawing hundreds of shading groups (I mean, pass) I thought the problem was calculate the geometry but this is not as big as the time used by the topics above. The problem is GP object creates a shading group for each stroke, so there are a lot of shading groups. Each shading group has its own uniforms because they can be different. We cannot use the z-depth because the first mandatory request is to keep 2D layer priority over z-depth. I mean, last stroke drawn is on top (the z-depth is not important). I remember trying to use a single shading group and hack the z-depth to get the right order, but this solution did not work and the result was very bad. Other problem is each shading group has its own GPUBatch data, so you have hundreds of small batches instead of a big one, so the clear is very heavy too. Finally, when you draw the pass, the CPU has to send a lot of shading groups to the GPU instead to send a big one. About GPU, the multisample and other GPU stuffs reduce speed, but they are not the main problem so we could improve later, but now the difference between on/off is maybe 2 or 3 fps, but use a lot of objects is maybe 40 fps. **Possible solutions** (original written by @fclem) * From what I can see you don't use any shader variations, so you can put all the stroke geom into one batch. Just put all geom in it and keep start index and count. With this you can just make calls using DRW_shgroup_call_range_add() with the order you want (using the first and last index). This will only make the VAO change if you draw a fill stroke or change object. This fixes point 1. * With some draw manager improvement (from me) you could even get rid of all the per stroke shgroup if you put every stroke uniform into UBOs and use the draw index to fetch the uniform value. This is how drawing lots of different meshes is done efficiently in vulkan/modern opengl. This would be even faster with the right opengl calls. This fixes point 2. * The next bottleneck then is the multisample blitting. Lots of possible saving here, ordered from simpler to harder: **Manually resolve the area that has been drawn by the layer's stroke. You can do that in two different ways. First is to use GL_SCISSORS, second is to draw a quad with the right size. This does however means that you have to compute the BBox of each object's layer.** Only resolve when next layer will overlap the previous. You can use the aforementioned BBox for that. Though I don't think this will have a lot of benefit since it will only skip maybe once per object (I'm not sure). ** Really complex but may worth the assle: draw each layer into a portion of the offscreen buffer and blit back using the techniques above only when the buffer is full. This would be much faster for small objects but not really if all layers fills the screen since it would just be equivalent to what we have now. Doing this also means keeping track of where the layer areas are and do some sort of naive realtime 2D packing. But this should fix 3 in most common cases.

Antonio Vazquez self-assigned this 2018-11-14 16:19:23 +01:00

Antonio Vazquez commented

2018-11-14 16:19:23 +01:00

Added subscribers: @WilliamReynish, @fclem, @antoniov