Hello Fabien! All bug reports received on Launchpad July-November came from systems which detected themselves as "OpenGL 2.1/GLSL1.20" (or less) or, if people used ANGLE, systems which ANGLE detected as "ps_2_0", which to my testings on only about 7 Windows (XP, 7, 8.1) PCs so far happens if those systems have no OpenGL drivers which would support GLSL1.30. All responding reporters who were able to update drivers accordingly could solve their problems.
I therefore implemented lots of startup tests which complain very verbosely and therefore hopefully clear enough for the average user (on first start only), but continue, if systems don't declare GLSL1.30 support. Timothy Reaves started a rant on Friday about too verbose debugs and messages on his Mac. He says his Mac has OpenGL 4.2, but the startup tests only finds OpenGL2.1 installed on his system. On Windows the answer string (glGetString(GL_VERSION)) always returns a string including highest OpenGL version supported, and OpenGL context or format (?) defaults to that. I assumed the same would be true on the other systems. He still has not answered whether this Mac that declares OpenGL2.1/GLSL1.20 in the logfile then works or has problems, but he tried to prepend GLSL1.30 to the shaders to make them work, which does however not work as I also had tested because GLSL1.30 syntax is different. It appears that while the syntax of the shaders is still (implicitly, by not specifying a #version line) GLSL 1.10/GLSL ES 1.00, they require hardware functionalities usually only available in systems which would also be able to compile GLSL1.30 (i.e., OpenGL3.0+ systems) or would fulfill ANGLE/DirectX's ps_3_0 tests. Note it is according to GLSL specs not even GLSL1.20 without a first line that says #version 120. (And specifying a line other than "#version 100" breaks OpenGL ES2/ANGLE...) I think a test with #version 120 caused a deprecation warning by NVidia's shader compiler, so syntax is GLSL1.10/GLSL ES 1.00 only. I *can only guess* that instruction count is too much on some systems (and you have seen the bugs from ANGLE/ps_2_0 systems), so maybe it is a critical OpenGL 2.1 extension (built into 3.0 or widely available on modern systems) which is used implicitly that should be tested at startup, but I have no idea which (I added this optional startup dump as first step, but my systems come with some 57 to 200+ extensions, so where is the needle in the haystack?). Bug reports come with either planets not rendered or stars not rendered. Almost all can be solved by updating to drivers which declare OpenGL3/GLSL1.30 level at startup, even if what they then compile may be "GLSL1.10 under the assumption of existence of extension ARB_XY". A single exception is my 2008 home PC with GeForce 8200/OpenGL3.3/GLSL3.3. It crashed whenever a Planet object came into viewport with 0.13.0, but works almost stable since V0.13.1, but still crashes *sometimes* when I zoom in to a Planet object. Maybe it's an issue in NVidia's XP drivers, or maybe it's a shader problem, I don't know. On https://www.opengl.org/wiki/OpenGL_Extension I find a section which may be relevant for Macs: ================ Targeting GL 2.1, but on GL 3-class hardware (mainly for Mac OSX versions without GL 3.x support): ================ So maybe on Macs some of these extensions listed there must be tested and activated explicitly before initializing an OpenGL context or so? Only a Mac developer can test this. And all startup and Qt-correct initialisation has to be changed for Qt5.4 anyways. Given that GLSL1.30 came with OpenGL3.0, a simple solution could be to test for OpenGL 3.0, and drop support for all lower systems when they cause needless trouble. Those would be put off to a possible V0.12.5. Also the hope that ANGLE would save all DirectX9/OpenGL2.0 systems turned out wrong. However, in the link you sent there is hint at an ANGLE that goes to DirectX11, which can fall back to software rendering if the hardware does not make it. Now, what is better, OpenGL with MESA or ANGLE translating OpenGL to software-rendering DirectX, this must be tested. Kind regards, Georg On Mo, 1.12.2014, 11:00, Fabien Chéreau wrote: > Hi, > what makes you think that GLSL 1.20 is not sufficient? If I introduced > non-compatible instructions in the planet code I should change them to > make > them GLSL 1.20 compatible, it should not be a big deal since I don't do > anything special in this code. > Fabien > > > On Sun, Nov 30, 2014 at 6:45 PM, Georg Zotti <georg.zo...@univie.ac.at> > wrote: > >> Hi! >> >> When I explicitly ask for an OpenGL2.1 format (edit StelMainView, line >> 375:) >> >> // Create an openGL viewport >> QGLFormat glFormat(QGL::StencilBuffer | QGL::DepthBuffer | >> QGL::DoubleBuffer); >> // GZ Test this on Win, Mac, Linux and FreeBSD! >> glFormat.setVersion(2,1); // Explicit setting was always >> missing! >> QGLContext* context=new QGLContext(glFormat); >> >> I still get a 4.4 format (i.e., the highest my GPU has) when tested >> later. >> What is the behaviour on a Mac, and on Linux? How would I set a version >> correctly? I used Qt5.2/MinGW. Is it different on Qt5.3? There is >> something NOT going on here as written in the Qt docs, as >> StelQGLWidget::initializeGL() is apparently never called (and was not >> called for years now!). >> >> So, I cannot turn OpenGL version down on Windows. Maybe this behaviour >> is >> different on a Mac? This is also a result gained from apparently >> excessive >> verbosity. A first step towards getting it right finally. >> >> BTW, with a config variable: >> >> QT_QPA_VERBOSE=opengl:1 >> >> you get lots of extra info. Not sure if this helps, though. >> >> Regards, G. >> ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
