Post #4407401

Squeezed one last optimization in after the v0.2-rc1 release that should land in the final v0.2. Filters now return a bitmask of flags that include the ability to advertise whether they can be appended to an existing command buffer (i.e. they are entirely or primarily GPU based and do not call begin() on the command buffer), and whether they can be appended to (primarily GPU based, and record into the command buffer but do not submit it). The scheduler now tries to identify as many blocks as possible that have no dependencies between them and submit them consecutively with no barriers. After adding a memory barrier, other blocks that depend on them can also be recorded to the same command buffer as long as there is no round trip to the CPU needed. The 100baseT1 benchmark was already real time (4x 20M points @ 12.5 Hz) on my workstation, but this optimization reduced the overall filter graph execution time from around 54 to 47 ms, a 15% speedup. Looking at profiling traces, the time from the start of the subtract filter to the end of the 100baseT1 decode filter went from 49.4 to 42.1 ms, a 17% speedup. No shaders were optimized, this is entirely from cutting out inefficiency caused by multiple Vulkan submit calls and GPU stalls between filter blocks. Total latency from the subtract call to beginning to render the waveforms went from 61.3 ms down to 53.5 ms, a 15% speedup. Unsurprisingly, everything is memory bound, even more than before since there's less downtime. Memory unit busy: 78.5% -> 83.3% Memory unit stalled: 33.2% -> 35.8% Write unit stalled: 16.7% -> 17.8% And the only reason these numbers aren't much higher is the remaining submit stalls that are harder to eliminate. But that's going to be more work, as will be optimizing the shaders to see if I can make more efficient use of memory bandwidth. But hey, 15+ percent speedup for a few hours of work? I'll take it.