On Sa, 29.11.2014, 13:57, Timothy Reaves wrote: > Why do you think the manor in which an OpenGL context is being created is > going to be of the highest version the computer supports? It couldn’t > possibly do this, unless your own development machine doesn’t go above > OpenGL 2 with GLES 1.3. The shaders used in the application are not > capable of being compiled with anything over GLES 1.3.
By testing QOpenGLContext::currentContext()->format()->version() e.g. around line 453 in StelMainView.cpp. Oh, I have already removed the qDebug() on this because it was redundant. ;-) This reports major:3 - minor:3 on my XP system with OpenGL3.3 drivers, without asking for it. So it is possible. I am still waiting for an answer whether trunk plays on your OpenGL2.1/GLSL1.20 Mac or which side effects you experience as user. The current shader syntax is compiled as GLSL1.10 unless you prepend a #version line. On an OpenGL ES 2.0 system (ANGLE), it is compiled as GLSL ES 1.00. If you prepend #version 130, you have to change it to GLSL1.30 syntax, and it will fail on OpenGL ES 2.0 systems because there is no GLSL ES 1.30. (This number jungle is a nightmare, indeed!) It may depend on particular OpenGL extensions which some OpenGL2.1 systems may have, others may not have, whether our shaders run or not. I have added this command-line-argument-triggered dump of OpenGL extensions so that someone knowledgeable in this may find out which are the relevant extensions. I have also read somewhere that useful extensions are incorporated by the OpenGL ARB as "main" feature in higher OpenGL versions, so that they don't have to be announced as extra extension. Apparently the relevant extension is in OpenGL 3.0, because we did not have bug reports from people where glGetString(GL_VERSION) returned a string that indicated OpenGL 3 or higher. (There apparently was a relevant change however in the OpenGL3 implementation between Mesa 10.1 and 10.3. I cannot say whether this was a bug in Mesa 10.1 or some extension which exists in all other OpenGL3 systems we had seen so far!) However, I don't belong to the group of experienced OpenGL/GLSL developers. It either takes thorough existing knowledge of GLSL1.10 and which extensions it is subject to, or a farm of 250 or so different PCs with "OpenGL 2.1 hardware" and drivers from 2006-2014 with complete logfiles and somebody to crosscheck extensions on good vs. bad systems. The optimal case would be if somebody knew which extensions are relevant so that the GLSL1.10 shaders work on that particular system even though they may be too long on other systems, then we could test for that extension, and not guesstimate that "OpenGL2.1+GLSL1.20 support indicates possible trouble that spans from slight nuisance to crash, while OpenGL3.* and declared GLSL1.30-or-higher support hints at trouble-free systems". A system *capable* of compiling GLSL1.30 or GLSL3.3 or GLSL4.2 can also compile our current GLSL1.10. A system *capable* only of compiling at most GLSL1.20 usually chokes on the current GLSL1.10 code. My 2008 OpenGL3.3 old home PC and 2014 OpenGL 4.2 netbook and 2012 OpenGL4.4 main system compile the current shader code nicely, because the version is unspecified and therefore defaults to GLSL1.10. However, apparently my card has much different limits on instruction count than my 2009 office PC with "OpenGL 2.1/GLSL1.20" Intel GMA. The latter still complains in V0.13.1 about some unresolved OpenGL functions, and shows a red box in night mode, but works OK in normal mode. The ANGLE version on this machine reports ps_2_0 and crashes within minutes. Others have reported real crashes with other "OpenGL 2.1/GLSL1.20" machines. The OpenGL3.3 home PC still running XP but current drivers sometimes crashes without log entry when I zoom into planets. Apparently there is another limit in this on-board GeForce 8200, or it's a matter of XP rotting away also for NVidia driver developers. If YOU can identify which extension or capability to test, this would be great, then we can remove all other tests. Else, just enclose all version tests in StelMainView.cpp with #ifndef MAC_OS_X or whatever excludes this from Mac compilation if it irritates you, and nothing will have changed over October's trunk in this respect. We may forward all driver-related Mac bug reports to you then. Again, how does trunk run on a Mac with OpenGL2.1/GLSL1.20? G. > >> On Nov 29, 2014, at 7:25 AM, Georg Zotti <georg.zo...@univie.ac.at> >> wrote: >> >> >> On Sa, 29.11.2014, 01:24, Reaves, Timothy wrote: >>> My hardware support OpenGL 5, and my driver supports 4.2. >> >> Maybe your hardware could do it. Your driver announced itself as 2.1, >> not >> or 4.2. >> >>> I can get this >>> with no issue in Qt. That's immaterial though; the app doesn't ask for >>> it. So by not specifying what version it wants, it actually gets 2.1 & >>> SL >>> 1.2. >> >> I understood in the meantime if the app does not ask for a specific >> version, it gets the highest available. Maybe requesting a particular >> version can be made in the move to Qt5.4 QOpenGLWidget etc classes. >> We never received bug reports for systems announcing themselves with >> providing OpenGL3/GLSL1.30 or higher (or with ANGLE, vs_3_0/ps_3_0), >> whereas ALL our reports came from systems only announcing themselves as >> supporting OpenGL2.1/GLSL1.20 (or on ANGLE: as being ps_2_0 instead of >> ps_3_0). Unfortunately, so far, we had no Mac reports. >> >>> And then the code complains, and offers to continue. Not good. >> >> It complains because only systems announcing GLSL1.20 showed problems. >> Some crashed, one has a minor issue in Night mode, therefore I consider >> "continue after warning" the best solution. >> >>> And the driver is not user upgradable. Nor in this specific case does >>> that matter. >> >> It does. Declaring OpenGL 2.1/GLSL 1.20 as highest feature level usually >> announces trouble. >> >>> I agree that most of the GL bugs are either in the drivers, or in Qt. >>> But >>> that's not the case here. It's clearly in the code you committed & >>> Alex >>> merged. And I know what is going on, and to a limited extent why. I'm >>> just not sure what to do about it. In the case, according to Qt, on a >>> Mac >>> you either get OpenGL 4.1 which means GLSL 4.1, or you get 2.1 with >>> GLSL >>> 1.2. So if your code is needed, as is not to be rolled back, then the >>> shaders will need to be upgraded to be compatable with GLSL 4.1. >> >> I have also tried to add #version lines. One problem is the necessity to >> run in Desktop OpenGL and OpenGL ES2, this could be circumvented with >> either prepending lines depending on ES-ness, or by having separate >> shader >> files. Without a #version line, the shaders are compiled (at least on >> NVidia drivers V340, but also found a note on this after long searches >> elsewhere) as GLSL1.10 or GLSL ES1.00, and the shader compilers accept >> this. If I add a GLSL1.30 line, shader compiler fails with deprecated >> syntax. So, although shader syntax is GLSL1.10 (and maybe, without >> having >> found confirmation, this is identical to GLSL ES 1.00), it only works >> nicely on systems declaring themselves to support GLSL1.30 or better. It >> is a matter of GPU registers, instruction count or whatever, I don't >> know >> a program that compiles GLSL1.10 and warns "line 38 will not run on a >> GLSL1.20 only system" or so. >> >>> That's >>> what I don't know how to do. I have a tracking branch where I am >>> attempting to make it work. It seems that the manor in which the >>> variables >>> are handled differs greatly. Feel free to have a look at it. >>> >>> But it really does seem to be as simple as upgrade the shades, or >>> revert >>> the changes. If I'm missing any other options, please, point them out. >>> Oh, yes, a third option would be to drop Mac support. >> >> Does the current trunk version, i.e. showing a warning panel ONCE which >> you can ignore, run on your Mac with the driver as you sent yesterday >> announcing OpenGL2.1/GLSL1.20? If this runs on a Mac, this is valuable >> information, and yet another test (or exclusion of the test if compiled >> on >> a Mac) will prevent you from seeing the warning panel. I have no Mac to >> try this. Such a configuration is however always missing something on >> Win >> and various *nices. >> >> 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 > > ------------------------------------------------------------------------------ > 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 > -- Dipl.-Ing. Dr. Georg Zotti Ludwig Boltzmann Institute for Archaeological Prospection and Virtual Archaeology (LBI ArchPro) Hohe Warte 38 A-1190 Wien ------------------------------------------------------------------------------ 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
