Large blend stack causes 10x slowdown in fine rasterization

[AlexVestin]

Was trying to familiarize with the structure and code and noticed one of the timings seemed off on my machine.

Running cargo run --release --bin cli Ghostscript_Tiger.svg had the Render kernel time at around 3 ms, while all other kernels were in the range of 0.02 to 0.15ms. Setting the MAX_BLEND_STACK to 1 in kernel4.comp the render kernel time drops to around 0.3ms, (and 1ms for MAX_BLEND_STACK 16). I tested with some other svgs (paper-1 and hawaii), which had similar results.

I had noticed the "large array per thread causing slowdown" in my own project previously, but have no idea if it is a my system issue since I've only tested with my own hardware. I'd be happy to help if any machine specific debugging is needed / close this issue if this only applies to my setup. I'm using a GTX 1070 and had the slowdown on both windows and linux.

[AlexVestin]

Ah #83 seems to cover this, should've commented there instead

[raphlinus]

No worries either way. This is useful feedback, and I'll take it on board when reworking the memory layout for the blend stack. Right now I'm leaning toward re-instantiating Elias' solution of counting up the blend stack space needed in coarse rasterization, but to avoid the problems of #83 put the blend stack in a separate binding so it can't slow the (performance critical) loads from the per-tile command list.

I'll probably create a new issue with the proposed plan going forward.