Navico RADAR Plugin Optimization

[NahanniV]

Starting this thread to continue discussion about optimization of the BR24radar_pi.

Originally Posted by boat_alexandra

....
I took a brief look at the radar source code, and if it's an issue with speed of rendering, then I'm confident that it can be made to run much faster. Right now the way it's pushing the stuff is not even close to efficient. As far as reading the data in via the network, I cannot be sure, but as it's already a background thread it probably isn't impacting performance too much. I think it should assemble the geometry in the background thread, and consolidate triangles (reduce triangle count) then push them in a single call when rendering which would be fast.

The other option would be to just push the raw radar data into a 2d texture, then use a fragment shader to render this texture very efficiently which would probably be by far the fastest method.


As far as the colors go, I think a lot could be improved, and a bunch of other things as well, but I don't think I'll have a lot of time to work on it.

Originally Posted by Douwe Fokkema

I would like to do that. Not difficult to map the current radar image in polar coordinates onto a 2D image in Cartesian coordinates. But which software to use to map this over OCPN? Preferably not openGL. Could you ask your contact?
Douwe Fokkema

[merrimac]

Douwe, there are two technologies that we can use within OpenCPN. OpenGL and wxWidgets. I'm pretty sure that OpenGL has better features and more performance for graphics than wxWidgets.

@boat_alexandra, which source did you check? Douwe has reduced the amount of triangles that we write considerably since the last production release. I personally don't think there is much of a performance problem on reasonable hardware. Yes, an underpowered processor with a deficient OpenGL implementation will be slow but then so will it when you use OpenCPN itself when scrolling or zooming.

Still, experimenting with a texture map would be a cool project, and maybe it will be faster. The question is whether it will work on all hardware, as you'd be using a 512x2048 2D texture or a 1x512 1D texture. One thing you could do is is distort the image a bit, and use a simple map of a (for instance) 512x16 2D texture onto a polygon, with 2048/16 = 128 segments building a circle.

If you are willing to tackle this, feel free -- that is what Open Source is about! I suggest you wait a while for the next production release though. I will integrate Douwe's improvements soon into the main branch and once that is tested release it as the next production version.

[seandepagnier]

Originally Posted by merrimac

Douwe, there are two technologies that we can use within OpenCPN. OpenGL and wxWidgets. I'm pretty sure that OpenGL has better features and more performance for graphics than wxWidgets.

@boat_alexandra, which source did you check?

The master branch in git from https://github.com/canboat/BR24radar_pi/

Douwe has reduced the amount of triangles that we write considerably since the last production release. I personally don't think there is much of a performance problem on reasonable hardware. Yes, an underpowered processor with a deficient OpenGL implementation will be slow but then so will it when you use OpenCPN itself when scrolling or zooming.

Ok, maybe he already did what I would have tried.

In any case, it isn't just the number of triangles, but how they are pushed. Using immediate mode is slow, they should be assembled into a ram buffer in the same background thread reading from the network socket. Then using a mutex, they can be pushed with a single call to glDrawArrays.

Still, experimenting with a texture map would be a cool project, and maybe it will be faster. The question is whether it will work on all hardware, as you'd be using a 512x2048 2D texture or a 1x512 1D texture. One thing you could do is is distort the image a bit, and use a simple map of a (for instance) 512x16 2D texture onto a polygon, with 2048/16 = 128 segments building a circle.

Using a texture could be faster on the right hardware, as you would have a shader program draw the texture in a ring. The more important part though, is the quality of the image rendered would be a bit better as well because it could interpolate pixel values, and the edges could be curved.. It would be a true circle not a polygon with lots of sides.

If you are willing to tackle this, feel free -- that is what Open Source is about! I suggest you wait a while for the next production release though. I will integrate Douwe's improvements soon into the main branch and once that is tested release it as the next production version.

I would but I don't have the hardware.

[merrimac]

Originally Posted by boat_alexandra

The master branch in git from https://github.com/canboat/BR24radar_pi/

Just rechecked, that code already coalesces triangles with the same color.

Originally Posted by boat_alexandra

In any case, it isn't just the number of triangles, but how they are pushed. Using immediate mode is slow, they should be assembled into a ram buffer in the same background thread reading from the network socket. Then using a mutex, they can be pushed with a single call to glDrawArrays.

Surely calling glDrawArrays would be almost as efficient even if called from the existing DrawRadarImage() method.

Originally Posted by boat_alexandra

Using a texture could be faster on the right hardware, as you would have a shader program draw the texture in a ring. The more important part though, is the quality of the image rendered would be a bit better as well because it could interpolate pixel values, and the edges could be curved.. It would be a true circle not a polygon with lots of sides.

Well, if you know how to do this super. I don't.

Originally Posted by boat_alexandra

I would but I don't have the hardware.

There is an 'emulator' built in that shows a fake image. Also we can ship you PCAP files with radar captures, that's how we develop off-ship as well.

[NahanniV]

Originally Posted by boat_alexandra

The master branch in git from https://github.com/canboat/BR24radar_pi/

Unfortunatly, I think you missed my link to the current development version:

https://github.com/douwefokkema/BR24...ee/integration

Originally Posted by merrimac

.... I personally don't think there is much of a performance problem on reasonable hardware. Yes, an underpowered processor with a deficient OpenGL implementation will be slow but then so will it when you use OpenCPN itself when scrolling or zooming.
....

What I hope can be achieved is a non overlayed display with reasonable performance on something like a Rpi2 or CubieTruck. I think these are similar hardware to what Navico uses in their chartplotters. OpenCPN is already running on the CubieTruck with very good response times.

Here is a link to a video I made showing the performance on the Cubietruck:

https://www.youtube.com/watch?v=2IV_Zq1bU-A

Cheers,
JM.

[merrimac]

Scroll speed with a bitmap is nice, have you tried it with vector charts?

The dev team (Håkan, Douwe, me) don't have any performance issues, even on older/slower hardware.

If you say that the performance is (too) low, can you substantiate? CPU% with the plugin active? Does it improve if you tune the radar gain way down so there are no blobs to draw?

For that type of hardware it might actually make sense to implement non-OpenGL drawing, which was never implemented (as Gradar didn't have it either.)

[NahanniV]

Originally Posted by merrimac

Scroll speed with a bitmap is nice, have you tried it with vector charts?

Yes, Raster charts are fastest, but ENCs work well too:

https://m.youtube.com/watch?v=VytrGiNxZ24

The dev team (Håkan, Douwe, me) don't have any performance issues, even on older/slower hardware.

I have other hardware with no performance issues as well. The compelling reason for these ARM based systems is extreemly low power consumption as well as low price. Typical power consumption of the board I am using is 3W.

If you say that the performance is (too) low, can you substantiate? CPU% with the plugin active? Does it improve if you tune the radar gain way down so there are no blobs to draw?

For that type of hardware it might actually make sense to implement non-OpenGL drawing, which was never implemented (as Gradar didn't have it either.)

The latest code is definitly better than previous versions, but downsampling has been removed and refresh rates above 1 do not speed up the refresh.

Sadly, my mast came down today for winter storage, however, I will setup a test system at home over the winter. Perhaps someone could post some sample capture files so that I could try to quantify the performance.
; The emulator is not really the same as the live data.

Cheers,
JM.

[seandepagnier]

Originally Posted by merrimac

Just rechecked, that code already coalesces triangles with the same color.

It doesn't seem to combine triangles in all possible cases. By this I mean, if they are next to each other in either angle or distance.

Surely calling glDrawArrays would be almost as efficient even if called from the existing DrawRadarImage() method.

Do you seriously think it is a good idea to use glBegin? It just isn't efficient. As far as non-opengl.. this would be terribly slow on these small computers. The performance difference with opengl vs software rendering is a lot more than a typical laptop, so it would really crawl.


The data should be packed into a vertex buffer object and pushed asynchronously. The vertex buffer should be assembled in a background thread. This would effectively reduce cpu usage in the main thread to zero.

Well, if you know how to do this super. I don't.

It would be a simple fragment shader which would convert texture coordinates from polar into rectangular to lookup using texture wrapping for the angle.

There is an 'emulator' built in that shows a fake image. Also we can ship you PCAP files with radar captures, that's how we develop off-ship as well.

I will keep it in mind.

[merrimac]

Originally Posted by boat_alexandra

It doesn't seem to combine triangles in all possible cases. By this I mean, if they are next to each other in either angle or distance.

It coalesces by distance. It keeps looping until the 'color' changes and then draws a blob (two triangles) of the desired height. Coalescing by angle was deemed to be too much work.

Originally Posted by boat_alexandra

Do you seriously think it is a good idea to use glBegin? It just isn't efficient.

None of us know any OpenGL. We have zero experience in it other than this code, which was just copied over from gradar. I looked at the OpenGL doc once to see if something stood out to be much better, but it is a complicated API if you don't know it nor know what you are looking for.

Originally Posted by boat_alexandra

The data should be packed into a vertex buffer object and pushed asynchronously. The vertex buffer should be assembled in a background thread. This would effectively reduce cpu usage in the main thread to zero.

It would be a simple fragment shader which would convert texture coordinates from polar into rectangular to lookup using texture wrapping for the angle.

You seem to really know this stuff so it would be really really helpful if you wrote some actual code. Just rewrite the drawing method, I can do the heavy lifting of moving the calculations to a background thread.

[NahanniV]

Can someone supply capture files of RADAR traffic.
Notes about how they work (loading) on your system might be helpful as well.

Thanks,
JM.

[Douwe Fokkema]

Originally Posted by NahanniV

The latest code is definitly better than previous versions, but downsampling has been removed and refresh rates above 1 do not speed up the refresh.

.

To prevent ignorant users from blocking their systems by putting the refresh rate higher than their system can handle, we have introduced Intelligent Load Balancing (ILB). The ILB takes care that refresh calls are skipped when system load is getting too high. Your case shows the ILB does its job.

Due to the far more efficient image build up in the last release, the influence of downsampling on performance became marginal. There was no justification to maintain it.

Douwe Fokkema

[NahanniV]

Originally Posted by Douwe Fokkema

To prevent ignorant users from blocking their systems by putting the refresh rate higher than their system can handle, we have introduced Intelligent Load Balancing (ILB). The ILB takes care that refresh calls are skipped when system load is getting too high. Your case shows the ILB does its job.

Due to the far more efficient image build up in the last release, the influence of downsampling on performance became marginal. There was no justification to maintain it.

Douwe Fokkema

Based on comparison between my laptop and my ARM system, I am wondering if the ARM system may be skipping refreshes even at the lowest refresh rate.

I think this may come up as people try to run this on the very popular RPi2 hardware as well.

Cheers,
JM.

[seandepagnier]

I started the optimizations today for rendering but stopped when my boat reached 37C inside.

[seandepagnier]

I need to somehow relay the radar to a different computer because mine has no ethernet port and I cannot get a usb ethernet adaptor here. How is it possible to do that?

I was using the raspberry pi which had ethernet but I trusted the 5 volt adaptor from the boat with the radar but unfortunately this 5 volt adaptor was not negative ground, but positive was 12v and negative was at 7v, so a ground loop through hdmi fried the raspberry.

[NahanniV]

Originally Posted by boat_alexandra

I need to somehow relay the radar to a different computer because mine has no ethernet port and I cannot get a usb ethernet adaptor here. How is it possible to do that?

I was using the raspberry pi which had ethernet but I trusted the 5 volt adaptor from the boat with the radar but unfortunately this 5 volt adaptor was not negative ground, but positive was 12v and negative was at 7v, so a ground loop through hdmi fried the raspberry.

Some suggestions:

-First make sure it works with the inbuilt emulator (may not load the system like the real RADAR).
-Use your CubieTruck.
-Use TcpReplay to replay captured RADAR data;
Either get a pre-captured file or make your own with WireShark.
-Try it with WiFi, apparently some routers will pass the traffic OK.

Hopefully your HDMI monitor wasn't damaged ?

Cheers,
JM.