We are developing a PPI plot for a radar system, similar to the following: NOTE: 1 radial is defined as a single slice of data within the circle, and 1 range gate is defined as a single point along a radial.
Our application must operate in real time, with large throughput and with a varying number of range gates per radial.
We have two implementations at the moment, both which stream radials to the GPU as vertex and/or texture data.
One version defines each range gate as separate primitives, then colors them using vertex coloring. The problem here is that the vertex buffer size must be rather large to accommodate a suitable amount of radials / range gates; this memory is not something we can necessarily rely on.
I am exploring another option, which generates one quad to represent each radial, then colors the range gates using texture mapping. The range gate texture buffer is a large 2D texture (2D to increase the maximum texture buffer size); 1D subsets of this texture are mapped to radials represent range gates. The problem with this method is that when a large number of fragments are being processed, each must perform a texture lookup to determine its color, which is wasteful since most fragments are redundant. This problem is compounded when zooming in, as every pixel in the window must sample the texture. The program's GPU usage skyrockets in these instances.
I've wondered if maybe it would be possible to sample each radial's 1D subset at the vertex level (since all vertices share a single 1D texture) then pass the sampled version to the fragment shader which then sample the subset. Each radial can have up to a thousand unique color samples. This would theoretically reduce the number of texture reads, but of course I don't even know if it's possible.
Is there an some way to optimize this process, or perhaps a way to reimagine the software that avoids some of these bottlenecks?