OpenCPN Beta Version 3.3.2222 Released

[seandepagnier]

Originally Posted by bdbcat

Gilletarom...

re:
"I made another test with O332222, VMH charts and GRIB plugin. "

I have been exploring this situation with the EeePC (1GB, intel 3150 GMA OpenGL)

I find that for my hardware, I cannot display overlays in GRIB because the OpenGL driver for GMA 3150 only supports OpenGL V1.4.

Is this in linux? OpenGL 1.4? Seriously?

I believe grib requires one of:
GL_ARB_texture_non_power_of_two
GL_OES_texture_npot
GL_ARB_texture_rectangle

You could extend the plugin to support primitive textures... but I would probably find a way to upgrade the driver instead.

Without overlays, it seems OK, all things considered. It does respond, as long as the scale selected is large enough. Small scale (zoom out) displays are much more difficult to render, and performance suffers.

We could use tiles, or at least upload subtextures to speed up the cases when we don't nee a full texture. This also applies for mipmaps.. but I can't see a case where it would matter.

But I think at some point we must agree that the datasets overwhelm the hardware. On my Win7 starter, the base memory usage (without any applications running) is about 500 MB. (by the way, this ought to be an embarrassment to Microsoft...) This leaves about 500 MB for OCPN. This is enough if using OpenGL with texture caching, or vector charts. But not really enough if we need to process a 1 GB GRIB file on top.

What about using texture compression here?

Are you able to use OpenGL with GRIB overlays? What about particles?

The particles truthfully could be recomputed when zooming to avoid compution for particles in the grib area that are not on screen. In this way also, more particles could be displayed when zoomed in, for an improved visualization.

It is also probably possible to run the particle display using shaders.

The isobar routine could be greatly speed up. The isochron routine used by climatology and wmm plugins is more than 10x as fast as the one in the grib plugin.

[Ptizef]

Dave, Sean

Another problem with the "big file" tests

When particles are running, I can't change any settings
I open settings, change something, close with OK : Nothing happens, my change is not applied.
I have to stop particles to get my change applied
It happens each time at big scale, but if I zoom in, at a certain zoom level, the phenomenon disappears.
Also with smaller files it doesn't happens
As already seen, particles stops some even
But I am not speaking about W8 and low power, but Vista and middle range power
and the last git 3.3.2301

Jean Pierre

[Ptizef]

Rick

When I check wind the particles start running. When uncheck particles stop.

This is right isn't it ?

When I check wind the waves get unchecked even when I have them as just arrows with no overlay and no numbers. And visa versa.

It don't work this way for me
If you have only barbed arrows + particles for wind and direction arrows for waves, you should be able to display both together. It's exactly what I showed you in the screen shot above

If I check Pressure, then Wind Gust is unchecked and visa versa. Have them as just isobars and arrows with no numbers.

This is quite normal if you want to display both pressure and wind gust as isobars. there is a conflict
Do you really want to display two different isobars ? This is easy to do but the result could be confusing

One of the keys was figuring out that you cannot check numbers on any of the first 4 data_types.

For me "Numbers" can be selected for all data types. But of course can be displayed for only one at a time

Jean Pierre

[rgleason]

I think I understand now. If an isobar type is displayed and you check another data_typr that uses isobar, the previous isobar data_type will be unxhecked, similat for anything using overlays. I did npt understand that action!

Maybe that is true for arrows (wind and wind gust )? Let me check it again.

Check uncheck wind turns on and off particles, wind arrows stay on because always on is checked. This action is as expected. Have yoi thought about the possibility of having particles as its own display type? Would it make operation and programming simpler and clearer? Particle action would still turn on and off from display screen but would be labled. Then if wind is checked always on there might be a check in that box. It does use more real estate.



Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[bdbcat]

jp...

re:
"When particles are running, I can't change any settings"

I tried this real quick, and I have no problem, even on netbook.

Do you mean the main OCPN options dialog, or do you mean the GRIB settings dialog?

What settings?

OpenGL, or DC mode?

Can you tell me the scale ranges where it works and doesn't?

Thanks
Dave

[bdbcat]

sean...

The OpenGL 1.4 is coming from the intel driver for GMA 3150 on Win7. No NPOT texture support at all. Even the labels on isobars are not shown in this mode.

I am testing OCPN hard on low power machines.

This is a pitiful situation, but unfortunately a not atypical user configuration. So I am focused on it.

Lots could be done in GRIB to optimize the drawing. This would of course help all configs. Its just a matter of dev resources.

Dave

[P_Dub]

Dave
What is the problem with otaining Grib files from saildocs wth Ed 3.3.2222?
Windows 7 Ultimate 64 bits, it does not seems to work for the request.
Any idea?
P_Dub

[cagney]

From the release notes

343. This Feature Request allows one to pre-designate a specific MMSI number for special handling. The choices should be intuitive. Of particular note is the idea that one can preset the MMSI numbers of onboard Personal Locator Beacons, so that a MOB from your ownship will be signaled immediately.

Thinking ...again. This statement isn't right.

A PLB is a personal EPIRB, transmitting directly to satellites. This signal has nothing to do with AIS. It is transmitted on a totally different frequency, Entering the MMSI of a PLB(EPIRB) will achieve nothing.

Unless....... we with a "Personal Locator Beacon" (also) means a device like this:SafeLink R10

Maybe we should say PLB(EPIRB) and PLB(AIS) ?

Thomas

[bdbcat]

cagney...

Right again. Needing to catch a signal from your own EPIRB will be not common. Maybe only to find it after your well-meaning guest tosses it over....

So, how about: "Handle this MMSI as SART/PLB(AIS) MOB."

Dave

[NahanniV]

I sent my old non SSE2 computer off to be recycled today; It was working fine but too many programs were not supporting it any more: Skype, Chrome... etc.

So, I am wondering if compiling the whole of OpenCPN with SSE2 would improve performance ?

Cheers,
JM.

[seandepagnier]

Originally Posted by bdbcat

sean...

The OpenGL 1.4 is coming from the intel driver for GMA 3150 on Win7. No NPOT texture support at all. Even the labels on isobars are not shown in this mode.

I am concerned with the labels on isobars. Does this mean also the labels for numbers don't work? What about chart texts? It should all be power of two textures for this, so I don't understand the problem.

For overlay support, Is there no driver to upgrade? If so, maybe we can even this case and suggest to the user to upgrade their driver. Otherwise, perhaps we can make a wrapper class to facilitate this, tiling power of two textures or non power of two textures as allowed to minimize memory use. This could be reused in other plugins like weatherfax as well.

I am testing OCPN hard on low power machines.

This is a pitiful situation, but unfortunately a not atypical user configuration. So I am focused on it.

Lots could be done in GRIB to optimize the drawing. This would of course help all configs. Its just a matter of dev resources.

Dave

Yes, well I think the two biggest are to allow subsets of the overlays using tiles and or subtexture uploads to cover only the area the viewport needs for that frame, as well as replacing the isobar routine with the one from climatology.

Of course particle support can be greatly enhanced as well.

[seandepagnier]

Originally Posted by NahanniV

I sent my old non SSE2 computer off to be recycled today; It was working fine but too many programs were not supporting it any more: Skype, Chrome... etc.

So, I am wondering if compiling the whole of OpenCPN with SSE2 would improve performance ?

Cheers,
JM.

You could try, but I doubt it would change much. As far as I can tell, we aren't even compiling using basic compiler optimizations under linux (this gives 30% speedup for everything) because it just isn't needed. The really slow stuff has to be addressed directly to speed up, and the compiler will rarely more than double the speed of the program (consider caching the compressed textures gave a 20x speed up)

The routine that we know really makes a big difference is generating the compressed textures, but this is because the code has been specially written (with 3 different versions) with the sse version hand written to use the sse specific instructions like _mm_add_ps etc...

You would be relying on the compiler to optimize the existing code to use sse instructions. Perhaps, generate assembly output for each file, and compare the difference to opencpn without sse, and see where the compiler uses sse instructions.

You would need to cleverly use these routines somewhere critical. I would start by profiling and determining the bottlenecks, but you would quickly find from this, the routines in georef.cpp (which converts the coordinates) do slow opencpn down a lot, and can potentially be rewritten manually with a special sse version which could more than double performance.

One possible speedup would be to configure everything to use 32bit floats as these are almost always faster. Even on 64bit systems because often they can perform more operations in parallel, and it's less memory to load and store.

Another possibility would be to "cheat" at least for vector charts since if the projection is not exactly mercator, it doesn't matter. In this case we could use a lookup table, and interpolate (with a special interpolation function specific to the mercator conversion) which is really close but uses few operations.

[bdbcat]

Hello testers...

Inspecting crash dumps again.
Once more I find a crash on opening Danish ENC chart DK2KATGN.

Anyone got a copy of this chart for test?

Thanks
Dave

[rgleason]

From the release notes
343. This Feature Request allows one to pre-designate a specific MMSI number for special handling. The choices should be intuitive. Of particular note is the idea that one can preset the MMSI numbers of onboard Personal Locator Beacons, so that a MOB from your ownship will be signaled immediately.

Thinking ...again. This statement isn't right.

A PLB is a personal EPIRB, transmitting directly to satellites. This signal has nothing to do with AIS. It is transmitted on a totally different frequency, Entering the MMSI of a PLB(EPIRB) will achieve nothing.

Unless....... we with a "Personal Locator Beacon" (also) means a device like this:SafeLink R10

Maybe we should say PLB(EPIRB) and PLB(AIS) ?

YES! Thomas you got that exactly right. The purpose of the AIS modifications is to support AIS PLB devices such that the home ship knows the MOB and there is an immediate alert... for best and quickest chance of recovery if own ship and mates are ok and the signal is received over the waves to the mast. Obviously the best likely signal is at the MOB start based on angles.

http://www.kannadmarine.com/us/safelink-r10
AIS MOB Devices

A huge Thank you for making these improvements!!!

[Ptizef]

Originally Posted by bdbcat

Do you mean the main OCPN options dialog, or do you mean the GRIB settings dialog?
What settings?
OpenGL, or DC mode?
Can you tell me the scale ranges where it works and doesn't?
Thanks
Dave

All my tests was made mainly in OpenGL mode with which I get generally the better result in all my configurations
I was speaking of the GRIB setting dialog
Opening it, changing a parameters and close it (thus validating by OK )... and nothing happened ...reopening it and noting that my change was lost
I noticed also that stopping particles just after the setting change permitted to activate this change
When I wrote this, it happens each time when the zoom level allowed to see the entire overlay (scale > 30000000)
Also the problem disappeared when zooming in but at that time, I didn’t noticed at which level
This night, I made new tests (same git level ) and the phenomenon appeared to be much less clear. It happened not each time, some time the change was not lost but only postponed for let's say 5 / 10 seconds.
Why this difference between two tests with the same environment ? may be a higher power demand due to others programs running in the background during the first tests?
mystery of Windows ?
But I can say that it didn't happen any more at a scale under 15000000

I tried also on the same machine (same git ) with Ubuntu 14.04 dual boot and I noticed any problem and globally higher performance.

I tried also with my low powered W8.1(same git)
With this big file I have the same problems I had at the beginning of particles:
- impossible to make change in the setting dialog ( when validate by OK)
- impossible to exit O
meaning that the changes (limiting CPU charge to 33%) works on this type of net-book only for medium and low file size

As in the meantime you have launched the new beta I'll soon test it

regards
Jean Pierre