Optimized Opencpn: Testers Needed

[seandepagnier]

Maybe it is safe to assume sse2 is supported on all cpus? Does anyone still use pentium 3's? Otherwise, maybe there is a way to compile support without sse instructions, and at runtime detect it?

[bcn]

From
SSE2 - Wikipedia, the free encyclopedia

The following CPUs implemented IA-32 after SSE2 was developed, but did not implement SSE2:

AMD CPUs prior to Athlon 64, including all Socket A-based CPUs
Intel CPUs prior to Pentium 4
VIA C3
Transmeta Crusoe

so this looks all > 10 years (with exception of some VIA C3 perhaps)

[CarCode]

Is it really a good idea to grogram for a particular CPU rather than to use the SDK of the OS? I am not sure about this.
As far as I know the programmers of games goes this way to make running their games with greatest performance and they program sometimes directly the hardware of CPU and GPU.

Gerhard

[seandepagnier]

There is no sdk of the os for sse instructions.

Since sse is not used for windows builds (it just runs slower for windows users right now) it would only affect linux users with really old hardware (in which case they can recompile without sse) but I doubt this is very likely so I think it's safe to use sse2. This will also likely improve performance elsewhere in opencpn.

One possibility is to use an opencl library which will automatically make everything work using run time detection, and run on cpu and/or gpu and use sse or whatever. It is likely modern gpus would make the cache operation about 10x faster using this.

[Hakan]

Originally Posted by Hakan

All ~400 charts loaded and the performance is still the same. Very good!............
Black square, more info:
All black squares are for CM93 parts named: "CM93Charts G 1/7500"
The black square are there when the viewport scale is from around 15000 to 7500, lower or higher scales are OK.
Håkan

Sean..
I've today pulled the last version based on 3.3.1618.
The black squares are still there.
There was a build error. VC didn't like the ambiguous sqrt call in ocpndc.cpp row 743, so I changed to:

 /* formula for variable step count to produce smooth ellipse */
        float steps = floorf(wxMax(sqrt(sqrt (float(width*width + height*height))), 1) * M_PI);

Håkan

[Hakan]

Plugin failure report...(On win32)
I tried to load the br24radar_pi plugin. It was loaded but with failures. I received the following log message:

14:21:49:   C:\Program\Opencpn_test\plugins\br24radar_pi.dll
              API Version detected: 108
              PlugIn Version detected: 40512
14:21:49: Error: BR24radar_pi: Unable to create UDP sending socket

Either the right click plugin menu is working, nor the preferrences button in the tool bar's plugin menu.

Everything is working in master 3.3.1618

[seandepagnier]

Originally Posted by Hakan

Sean..
I've today pulled the last version based on 3.3.1618.
The black squares are still there.
[/CODE]Håkan

Could you try with course up mode and see if the black squares are there? Please ensure that the course is something besides north, may require vdr or using a gps.

Next, try on glChartCanvas.cpp:2179 change "#if" 1 to "#if 0", and see if this has any effect. Finally, try changing glChartCanvas.cpp:1015 m_b_DisableFBO = false, to true.

[NahanniV]

Originally Posted by boat_alexandra

Maybe it is safe to assume sse2 is supported on all cpus? Does anyone still use pentium 3's? Otherwise, maybe there is a way to compile support without sse instructions, and at runtime detect it?

My home PC is an AMD Athelon XP 3200+.
Google Chrome recently started telling me my hardware will soon be unsupported. Turns out the issue is SSE2 support.

So, if Google is dropping support for NON SSE2 processors I guess it is safe for you to do it too.

I will likely soon scrap my antique desktop anyway.

JM.

[Hakan]

Originally Posted by boat_alexandra

Could you try with course up mode and see if the black squares are there? Please ensure that the course is something besides north, may require vdr or using a gps.

Right! Playing VDR and as soon the canvas up is not north the black squares are gone. When COG & SOG occasionally are zero and north is upp the squares are back.

Next, try on glChartCanvas.cpp:2179 change "#if" 1 to "#if 0", and see if this has any effect

Yes, no black squares neither in north up nor course up.

Finally, try changing glChartCanvas.cpp:1015 m_b_DisableFBO = false, to true.

With row 2179 back to #if 1, this has no effect. In north up the black squares are there, in course up there are no black squares.

I really appreciate your performance work. When I very often stop and start OCPN like in this tests the code changes are obvious. The program starts nearly immediately compared to the master version.
Thanks, Håkan

[seandepagnier]

Originally Posted by Hakan

Right! Playing VDR and as soon the canvas up is not north the black squares are gone. When COG & SOG occasionally are zero and north is upp the squares are back.

Yes, no black squares neither in north up nor course up.
With row 2179 back to #if 1, this has no effect. In north up the black squares are there, in course up there are no black squares.

I really appreciate your performance work. When I very often stop and start OCPN like in this tests the code changes are obvious. The program starts nearly immediately compared to the master version.
Thanks, Håkan

Hooray.. so this was the last lingering issue.

I think you driver has some bug related to scissor mode (which is an optimization I added). Can only be used in north-up mode. Because changing 2179 to #if 0 disables the scissor test reverting back to the slower stencil or depth test.

Since this is only an issue for you, maybe you can post your opencpn.log and we can detect it at startup and have a special case which disables the scissor optimization for your specific rendering hardware.
.

[Hakan]

Originally Posted by boat_alexandra

Hooray.. so this was the last lingering issue.

I think you driver has some bug related to scissor mode (which is an optimization I added). Can only be used in north-up mode. Because changing 2179 to #if 0 disables the scissor test reverting back to the slower stencil or depth test.

Since this is only an issue for you, maybe you can post your opencpn.log and we can detect it at startup and have a special case which disables the scissor optimization for your specific rendering hardware.
.

It could be that my dated PC and equally dated graphical card can be the issue. Since I'm probably not the only one with stuff like this it could be worth to make an adaptation.
The log from today attached. (Discard .pdf)

[ChuckSK]

I have been seeing "Display Driver Stopped Responding" errors. Two areas are particularly fruit-full in producing these errors. 51N 1.25E and 46N 31E. The charts are cm93. I have been able to stop these errors by 2 methods. 1: Turn off all the Traffic Separation Scheme objects in Mariner's Standard. 2: Adding a couple lines of code in s52plib.cpp to bypass using a texture for rendering raster symbols. Neither is a good solution.

Here is a portion of the .ini file to show the chart stuff.

CM93DetailFactor=0
CM93DetailZoomPosX=248
CM93DetailZoomPosY=680
ShowCM93DetailSlider=0
AllowExtremeOverzoom=1
SkewToNorthUp=0
OpenGL=1
GPUMemorySize=448
SmoothPanZoom=1
UseRasterCharts=1
UseVectorCharts=0
UseCM93Charts=0
CourseUpMode=0
LookAheadMode=0
COGUPAvgSeconds=1
OwnshipCOGPredictorMinutes=5
ChartQuilting=1
FullScreenQuilt=1
ChartQuiltingInitial=1

Here is a portion of the log file to show the driver stuff.

16:04:17: OpenGL-> Renderer String: Intel 965/963 Graphics Media Accelerator
16:04:17: OpenGL-> Detected Intel renderer, disabling stencil buffer
16:04:17: OpenGL-> Detected Intel renderer, disabling FBO
16:04:17: OpenGL-> Texture rectangle format: 84f5
16:04:17: OpenGL-> Framebuffer Objects unavailable
16:04:17: OpenGL-> Using Depth buffer clipping
16:04:17: OpenGL-> Using s3tc dxt1 compression
16:04:17: OpenGL-> Compressed tile size: 128kb (6:1)

This one has me stumped.

Chuck

[seandepagnier]

Originally Posted by ChuckSK

I have been seeing "Display Driver Stopped Responding" errors. Two areas are particularly fruit-full in producing these errors. 51N 1.25E and 46N 31E. The charts are cm93. I have been able to stop these errors by 2 methods. 1: Turn off all the Traffic Separation Scheme objects in Mariner's Standard. 2: Adding a couple lines of code in s52plib.cpp to bypass using a texture for rendering raster symbols. Neither is a good solution.

Here is a portion of the .ini file to show the chart stuff.

CM93DetailFactor=0
CM93DetailZoomPosX=248
CM93DetailZoomPosY=680
ShowCM93DetailSlider=0
AllowExtremeOverzoom=1
SkewToNorthUp=0
OpenGL=1
GPUMemorySize=448
SmoothPanZoom=1
UseRasterCharts=1
UseVectorCharts=0
UseCM93Charts=0
CourseUpMode=0
LookAheadMode=0
COGUPAvgSeconds=1
OwnshipCOGPredictorMinutes=5
ChartQuilting=1
FullScreenQuilt=1
ChartQuiltingInitial=1

Here is a portion of the log file to show the driver stuff.

16:04:17: OpenGL-> Renderer String: Intel 965/963 Graphics Media Accelerator
16:04:17: OpenGL-> Detected Intel renderer, disabling stencil buffer
16:04:17: OpenGL-> Detected Intel renderer, disabling FBO
16:04:17: OpenGL-> Texture rectangle format: 84f5
16:04:17: OpenGL-> Framebuffer Objects unavailable
16:04:17: OpenGL-> Using Depth buffer clipping
16:04:17: OpenGL-> Using s3tc dxt1 compression
16:04:17: OpenGL-> Compressed tile size: 128kb (6:1)

This one has me stumped.

Chuck

The message "Display Driver Stopped Responding" you receive how?
Is this the graphics driver?

My intel driver sometimes prints to console "stuck in the render ringbuffer" which is coming from kernel space. Of course it takes 20 seconds to switch to the console because the computer is completely locked up during this time (sometimes sound output repeats like broken record depending on how the interrupts got handled during this time) Very annoying. This has nothing to do with opencpn, but unfortunately certain operations can trigger it. Sometimes I am also forced to reboot the machine (at least it boots in 5 seconds)

Intel drivers are very buggy.

Anyway, I think the solution is to debug the intel graphics drivers which I haven't gotten around to yet but did plan to attempt. Another option is to try commenting the bit out that disables stencil mode for intel graphics. Maybe it has issues with the depth buffer, but this didn't help my problem.

[ChuckSK]

The message is from the operating system. It restarts the graphics driver automatically. OpenCPN is aborted in the process.

I will make personal changes to s52plib.cpp to bypass using textures to render raster symbols. The improvement in speed was not noticeable.

[ChuckSK]

A couple more discoveries.

1. Changing from opengl to normal graphics locks the chart canvas. It behaves as if there is a hidden open dialog waiting for a response.

2. With opengl, mouse rollover of routes and AIS targets causes screen flashing.

Chuck