OpenCPN and Navico radar freezing on Intel 4000 video controllers

[Douwe Fokkema]

Problems with OpenCPN, br24radar_pi and radar_pi on Intel Graphics 4000 (and sometimes also 3000) video controllers under Windows 10.


On my ships computer I had since a long time persistent problems with the Navico radar PPI windows. As soon as I opened a PPI window for the second radar, the system froze, with response times of several seconds, often resulting in a crash. To solve this problem once and forever I built out the system from the boat and took it home for further analysis. First I freshly installed Windows. To my surprise problem had gotten worse, system was now freezing when opening the first radar PPI window.
I had never seen this issue on my main development system. This system has a NVIDIA Geforce video controller. But there is still an on-board Intel 3000 video to which I connected my monitors. Result: even OpenCPN was now freezing. I could drag the chart once or twice, then it froze for several seconds. I started playing with the OpenGl options. Problem occurred only and always when the "show FPS" was on. I looked into the code, g_bShowFPS was set and some counters handled. But also a glFinish() was issued. I searched internet for glFinish and Intel 4000 video. Found: https://www.opengl.org/discussion_bo...4000-War-Story
Then I took out all glFinish() statements from radar_pi and OpenCPN as follows (for OpenCPN):
@@ -3386,7 +3386,7 @@ void glChartCanvas::Render()
if(b_timeGL && g_bShowFPS){
if(n_render % 10){
- glFinish();
+ // glFinish();
g_glstopwatch.Start();
}
}
@@ -3848,13 +3848,13 @@ void glChartCanvas::Render()
#ifdef __WXMSW__
// MSW OpenGL drivers are generally very unstable.
// This helps...
- glFinish();
+ // glFinish();
#endif
SwapBuffers();
if(b_timeGL && g_bShowFPS){
if(n_render % 10){
- glFinish();
+ //glFinish();
double filter = .05;
Result: problem solved completely. Both OpenCPN and radar_pi run perfectly even with show FPS option on.

[rgleason]

Douwe,
I have a Dell Inspiron Laptop 1502 with dual display cards, Nvidia Geforce 540M and Intel HD4000 thanks for the alert.

Since we don't have an Intel HD 4000 GPU to test with here we had to have the customer try our new software builds and send us logs. The customer is on the other side of the world, so the cycle time was typically one day. Fortunately he was very patient and careful.

Long story short, we figured out that the Intel HD 4000 absolutely HATES glFinish(). It causes long internal timeouts. Even with just ONE glFinish command in our rendering loop it would cause havoc. So I recommend:

Use no glFinish() commands to synchronize the GPU and CPU with the Intel(R) HD Graphics 4000.

We also learned that it will fail glReadPixels calls if you set glReadBuffer and/or glDrawBuffer to GL_NONE at some prior point in operation, even if you have the proper things bound at the time.

Don't set glReadBuffer or glDrawBuffer to GL_NONE with the Intel(R) HD Graphics 4000.

Finally, we're still seeing a number of these emitted when we destroy the rendering context (possibly one per shader):

From OpenGL API, in Rendering Context 00040006: OpenGL API Error
Debug Frame = 'None'
ID = 1281
Message = GL error GL_INVALID_VALUE

Errors during cleanup don't affect the customer experience, but we're still going to think through what could be going wrong and try to correct it.

[Hakan]

Douwe..
Since also HD 3000 was mentioned in the text from Rick I tried your fix on my HD 3000 machine. It seems to work wo failure. Radar_pi with your fix is fine also on my PC.
Please find my test code on OCPN herein. We may test this more and come back for PR?
/Håkan

diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index d22aa8b57..19b82f459 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -181,6 +181,7 @@ extern TCMgr            *ptcmgr;
 
 
 ocpnGLOptions g_GLOptions;
+bool g_IntelHD3_4000 = false;
 
 //    For VBO(s)
 bool         g_b_EnableVBO;
@@ -732,6 +733,13 @@ void glChartCanvas::SetupOpenGL()
 
     bool bad_stencil_code = false;
     if( GetRendererString().Find( _T("Intel") ) != wxNOT_FOUND ) {
+      // HD Graphics 3000 and 4000 "hate" glFinish(). Dont use it for these cards.
+      if (GetRendererString().Upper().Find(_T("HD GRAPHICS 3000")) != wxNOT_FOUND ||
+        GetRendererString().Upper().Find(_T("HD GRAPHICS 4000")) != wxNOT_FOUND )
+          {
+        wxLogMessage(_T("OpenGL-> Detected Intel HD Graphics 3 or 4000, disable glFinish") );
+        g_IntelHD3_4000 = true;
+      }
         wxLogMessage( _T("OpenGL-> Detected Intel renderer, disabling stencil buffer") );
         bad_stencil_code = true;
     }
@@ -884,7 +892,7 @@ void glChartCanvas::SetupOpenGL()
             wxLogMessage( _T("OpenGL-> Detected Windows Intel Mobile renderer, disabling Frame Buffer Objects") );
             m_b_DisableFBO = true;
             BuildFBO();
-        }
+        }        
     }
 #endif
     
@@ -3388,7 +3396,7 @@ void glChartCanvas::Render()
 
     if(b_timeGL && g_bShowFPS){
         if(n_render % 10){
-            glFinish();   
+            if (!g_IntelHD3_4000) glFinish();
             g_glstopwatch.Start();
         }
     }
@@ -3850,13 +3858,13 @@ void glChartCanvas::Render()
 #ifdef __WXMSW__    
      //  MSW OpenGL drivers are generally very unstable.
      //  This helps...   
-     glFinish();
+     if (!g_IntelHD3_4000) glFinish();
 #endif    
     
     SwapBuffers();
     if(b_timeGL && g_bShowFPS){
         if(n_render % 10){
-            glFinish();
+            if (!g_IntelHD3_4000) glFinish();
         
             double filter = .05;

[Douwe Fokkema]

Hi Hakan, good idea distinguishing in the code between Intel 3000/4000 and other controllers. But the question is: is the glFinish() really needed? It could be replaced with a glFlush(), but that also does not seem required. There is a nice discussion about these commands in: https://stackoverflow.com/questions/...sh-vs-glfinish. Summerizing I would say that glFlush()) empties the buffer towards the graphics controller and glFinish() does the same but also waits until the graphics controller has finished all operations. But the conclusion I draw from it is that none of these commands is required in out situation. And as far as I can test both OpenCPN and radar do perfectly without. I also had the impression that O was starting up quicker (not measured).

[Hakan]

@Anyone, Dave?, Pavel?, Kees?

I've tested wo glFinish on Win10 and Intel HD Graphics 3000.
So far I've found no obstacles or disadvantages. Moving, zooming, gribs, AIS, radar_pi, ARPA..... All views are fine and quick responding. Is there anything I can test to verify we don't need it for a system like mine?
Thanks
Håkan

[bdbcat]

Hakan...

The restrictions imposed by OCPN on Intel embedded GPU and OpenGL are based largely on very early experiences with some now obsolete chipsets.
There are other performance limiting restrictions as well. Consider, for example:

    if( GetRendererString().Find( _T("Intel") ) != wxNOT_FOUND ) {
        wxLogMessage( _T("OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects") );
        g_b_EnableVBO = false;
    }

Result: we presently disable VBO on all Intel platforms. This can be a significant performance hit for vector charts. But probably this is not required on modern Intel hardware.

We read that the performance and compatibility of Intel GPU and GL drivers has improved considerably in the past few years. So it may be time to relax some of the OCPN restrictions.

What we need is extensive regression testing for the relaxed restrictions. I am pretty sure that there are a lot of boat computers that are 6-8 years old, possibly running XP. We would not like to require them to revert to non-GL mode to run our latest version.

So, we will have to be very explicit on the GetRendererString() results to determine what features will work on which Intel chipset version. A big matrix....

I propose that we make a point to target some of this as part of our next Beta test series, and see how it goes.

We can start by saying that it appears that glFinish() is not required, nor desired, by Intel HD Graphics 3000. That is a start...

Dave

[Hakan]

Dave..
Very good, thanks.
I'll make a PR.

Håkan

[Douwe Fokkema]

Just tested on board. The new Intel driver for Windows 10 (version 15.33.47.5059 dated 9/18/2018) for the Intel HD Graphics 4000 solves the above problems. See https://downloadcenter.intel.com/dow...?product=81499
For the HD Graphics 3000 no new driver exists and problems remain as before, requiring fixes in OpenCPN and br24radar_pi. But as this new driver for HD 4000 does not come automatically with Windows update, many users might miss it. So while fixing issues for 3000 I would suggest to include 4000 as well. Or just remove glFinish(), I have not yet seen a situation where it harms.

[rgleason]

I can download the new driver or not as you wish, and test. Which way do you want me to test? I believe Hakan has confirmed the radar works, so this would be for o with Intel HD 4000

[Douwe Fokkema]

I have tested the released version of O4.8.6 with the released version of br24radar_pi. Before loading the new driver radar PPI windows frozen, after installing the new Intel 4000 driver all OK.

I do not think a lot of additional testing is needed. But the question is if we still want to solve the problems in O and radar software for the old driver. I would suggest to solve them so that the O and radar run also with the old driver. Many users will not know that there is a new driver now and will not install this driver.

[rgleason]

Thanks Douwe, I just ran Intel Driver & Support Assistant, prior to installing the driver and found that I have HD 3000 and there is no update! I also checked under system > device manager and found the same!
The Intel Support Assist shows it is running the most current drivers available for Intel HD3000:

• Driver ProviderIntel Corporation
• Driver Version9.17.10.4459
• Driver Date5/19/2016

I guess those tweeks would help this graphics card operate properly too. I believe I can also direct the program Opencpn to use the Nvidia Card too.

[Tupaia]

Originally Posted by bdbcat

Hakan...
What we need is extensive regression testing for the relaxed restrictions. I am pretty sure that there are a lot of boat computers that are 6-8 years old, possibly running XP. We would not like to require them to revert to non-GL mode to run our latest version.
Dave

Just a suggestion we used to run into this situation quite often and it caused our customers great consternation when "old" systems stopped working but at the same time held up progress of new features.

We introduced an on screen Legacy switch stored in the ini file, the existence of which prompted the program to check a Legacy file for various parameters that would give access to loops into "old" subroutines.

Because there was only a single parameter carried through it meant that the mainstream system would skip any legacy code and not be slowed and any further parameters would only be read by systems needing to use bits of the legacy code.

It also meant that hardware problems could be easily identified in the field.

[rgleason]

That's not a bad idea, but it does add some complexity to the code, but of course that is not my department.

I was just starting to think we should be looking at new laptops pretty soon. Our XP Desktops are no longer supported by MS and our Laptops which are newer are now getting a bit long in the tooth.

I think some old sailors who have old salty XP machines should really consider donating to the recycle bin. Even low powered new machines will be more efficient and powerful.

Then the developers would not be restrained by old code issues, coding would be easier and OpenCPN would run better. I think the programming crew has done an incredible job keeping XP in the mix and it might be getting time to let it go. If not with the next version, most certainly with the one after that!

--Just my opinion.

[petter5]

I would rather say "donate windows" to the recycle bin. Most laptops made the last 15 years will feel like a Tesla S in performance if you upgrade from windows to for example Xubuntu. I have installed Opencpn for a lot of folks on "slow" laptops where the laptop have been upgraded form Windows to Xubuntu and after that the laptop run opecpn smoooooth.

Originally Posted by rgleason

That's not a bad idea, but it does add some complexity to the code, but of course that is not my department.

I was just starting to think we should be looking at new laptops pretty soon. Our XP Desktops are no longer supported by MS and our Laptops which are newer are now getting a bit long in the tooth.

I think some old sailors who have old salty XP machines should really consider donating to the recycle bin. Even low powered new machines will be more efficient and powerful.

Then the developers would not be restrained by old code issues, coding would be easier and OpenCPN would run better. I think the programming crew has done an incredible job keeping XP in the mix and it might be getting time to let it go. If not with the next version, most certainly with the one after that!

--Just my opinion.

[rgleason]

That's a reasonable suggestion for those who use only Opencpn on a dedicated boat computer, however there are many programs we use that do not run with Linux, including our CAD program.


I think this option or ones like it should have a thread dedicated to it. So that users converting from Windows to whatever flavor of Linux can share there experiences:
1. Installation problems.
2. Hardware issues.
3. Software replacements.
4. Success stories
5. Failure stories.

These types of OS Conversions could be posted in the OS Linux specific thread which is listed in the Plugin Links sticky thread but we could add a thread "OS Linux conversions from Windows" if there were some good examples, it might become a trend.

I don't think the graphic controller issue would be resolved however.
I'm lucky because this computer also has an Nvidia Geforce 540m which can be directed to run Opencpn.


So that is another good alternative, to fit another graphics card into the computer.