We are developing a PPI plot for a radar system, similar to the following: http://radar-review.blogspot.com/2014/04/ 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?

  • $\begingroup$ What do you refer to as vertices? Triangle vertices? So you are using a triangle mesh to draw this? As opposed to simply a texture? Can't you just generate a suitable 2d texture that you apply on a single quad? By this I mean a texture which has this circle with the radials in the middle. If you do this your problem with reduce to simply generating the correct texture fro your data (you do something similar currently from what I gather anyways but very inefficiently). $\endgroup$ – lightxbulb Mar 7 '19 at 16:41
  • $\begingroup$ One approach generates a mesh for each radial (a triangle strip), where each range gate is described by a quad (really, two triangles). The second approach attempts to describe range gates by mapping a 1d texture onto each radial (a single quad). $\endgroup$ – Matthew Herndon Mar 7 '19 at 16:52
  • $\begingroup$ Yes but why? Both of these generate a lot of triangles. Why not just make a quad and map a texture on it? Surely that will be more efficient. All you would have to do is to generate that texture. The second variant is not so terrible though, even though you generate a bunch of triangles. It really comes down to what your requirements are (in terms of resolution/zooming) and what your initial data looks like. I assume your initial data is resolution limited. What would be that initial resolution per radial and how many radials do you have. $\endgroup$ – lightxbulb Mar 7 '19 at 16:57
  • $\begingroup$ The problem is that given the data we're expecting, there isn't really a trivial way to generate the circular texture you described in real time. As data arrives, it will need to be mapped to a radial at some arbitrary angle. That's the crux of the problem. $\endgroup$ – Matthew Herndon Mar 7 '19 at 17:03
  • $\begingroup$ Join the chatroom if you want so we can clarify in real-time what you mean: chat.stackexchange.com/rooms/90733/… $\endgroup$ – lightxbulb Mar 7 '19 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.