Dear Timothy, My feeling was that maybe 80% of reported "bugs" (apart from misunderstandings) since July were those by people with outdated GPUs or at least outdated drivers on several operating system configurations which to my knowledge are not regularly tested by developers, zillion hardware variants that go back in parts to 2003, and so on. I was trying to identify the most likely culprits and understand under which circumstances systems "don't work for me":
OpenGL less than 2.1: No-go. Tell the user sorry, and exit. OpenGL drivers reporting only 2.1 support: we had at least two reports on missing stars. On other systems, only minor issues in Night Mode, therefore I would consider this "runnable with acknowledged problems". shader support for GLSL1.20 only: reports about missing planets. ANGLE reporting ps_2_0 support only: shaders are too long, no planets. Mesa <10, reported with modern Radeon card on FreeBSD: stars missing. So what? If I test all those on startup and tell the users that problems are known to follow, and we cannot do much about them unless they update their systems, why is that a bad idea? We will get less of those reports, hopefully. I did not understand what you mean by "broken code" > There is so much wrong with this, but, put simply, the application > requests OpenGL 2.1 with GLSL 1.2, then tells the user to upgrade their > hardware as this level of support is not sufficient for the app. Wow. The app does not "request" OpenGL2.1+GLSL1.20, it only detects what the driver provides and states this may not be enough, but offers to continue. > And if I actually update the code to request & use the highest-supported > versions, then the app crashes with the shaders failing to compile. What did you update in the code? Have you updated your *drivers* as instructed? Or why did shader compilation fail? Did the program work normally after you have acknowledged/"ignored" the warning panel (then the test needs to be sharpened and you, on a Mac with NVidia, should not see the warning, but my IntelGMA/Win7 Office PC must still see it, and likely various Linuces with either proprietary NVidia or Radeon drivers or Mesa also must see it), or did you experience graphics problems? New drivers should come with OpenGL 4 for your card, so what prevents you from upgrading, or is that still 2.1 on Macs? If you just ignore the message, I expect that the installed OpenGL2.1+GLSL1.20 combination is not enough to run Stellarium (as has been reported and experienced on several non-Mac systems), and this is what the message panel tells you, exactly one time, on first run. Putting another log entry here indicates to us logfile readers that user continued on a likely broken system. I have actually meanwhile found that the current shaders are #version-lessly compiled as GLSL1.10/GLSL ES1.00, but testing for GLSL1.30 support gives at least some confirmation that hardware and drivers fulfills modern standards. There is unfortunately still no definitive answer for me on the relation between OpenGL hardware driver strings and ANGLE's translation to DirectX 9, I only could see that systems which report GLSL1.20 support always report as ps_2_0 in the ANGLE driver string, and fail to show the planets because the shader is too long. And NVidia PCs with 6800 and 7300 cards were reported to miss the planets in OpenGL mode. They are GLSL1.20 cards. Now tell me what I can test better? Maybe tell me even why my 8200 (could deliver OpenGL3.3/GLSL1.30) crashes *sometimes* when I zoom in to planets. With the diagnostics branch, I originally only wanted to get rid of those lousy usually log-less bug reports, then Fabien asked me to get rid of now-deprecating Qt classes. Sorry, I could not finish this process, the topics "context", "surface", "window" , "widget", etc. are a bit too involved for me, while it may only take half an hour for the better developers like you, and when 5.4 likely brings more changes. Therefore I have prevented these parts from compilation (they don't disturb in any way, but may already be valid steps towards a solution) until someone more knowledgeable like you takes over. The branch with all those tests was under merge proposal for several weeks to gather objections and improvements, and it was even open to commits by stellarium team. If you look into various bug reports and logfiles sent on second and third request by "does not work"-bug reporters, the OpenGL driver strings are very vendor-dependent. Sometimes the OpenGL version number is in front, sometimes in the back, there is no standard. Therefore it might seem a bit verbose at the moment to print full string and what I try to decipher. What if parsing fails? I don't consider an extra line in a logfile a problem, but hope that with a few more than ~2 PCs per currently active developer to test this we get a larger sample of driver message strings reported by people testing intermediate versions and still having problems, in order to enhance usability of, and further sharpen, those admittedly stupid, but apparently necessary startup tests. It is unlikely anybody on those platforms would compile their own versions from a branch, so this had to go into trunk to get more circulation in the "testing versions" which Alex is friendly enough to build almost weekly. Debug log entries can easily be taken away before next RC or release, when hopefully this testing orgy could be stabilized. Else, please tell me a better solution than having no tests for known-to-be-outdated hardware and definitely not enough diagnostics, as we had in July. Regards, Georg On Fr, 28.11.2014, 17:27, Timothy Reaves wrote: > OpenGL is a complex development topic, and the marriage of Qt, OpenGL, > OpenGL ES, and their shading languages, and the apps over-riding both the > Qt app and the Qt GL widget, has always been difficult. The last commits > by Georg & merged in by Alex just make things worse, and need to be > reverted. Georg, if you’re working towards something new for Qt 5.4, I > applaud that, but, it should be kept in a separate branch until completed, > and Alex, you should have merged it until it’d been conformed to work on > all OS’es. > > Let’s have a look at the current broken code. The following is from one > of my Mac’s. > > Detected: OpenGL "2.1" > Driver version string: "2.1 NVIDIA-10.0.43 310.41.05f01" > GL vendor is "NVIDIA Corporation" > GL renderer is "NVIDIA GeForce GT 650M OpenGL Engine" > GL Shading Language version is "1.20" > GLSL Version Number after parsing: 1.2 > This is not enough: we need GLSL1.30 or later. > You should update graphics drivers, graphics hardware, or use the MESA > version. > Else, please try to use an older version like 0.12.4, and try there with > --safe-mode > Config option main/ignore_opengl_warning found, continuing. Expect > problems. > > > There is so much wrong with this, but, put simply, the application > requests OpenGL 2.1 with GLSL 1.2, then tells the user to upgrade their > hardware as this level of support is not sufficient for the app. Wow. > And if I actually update the code to request & use the highest-supported > versions, then the app crashes with the shaders failing to compile. > > With the lnksidasical development we have, this may be an insurmountable > issue. But I think we need a well though out, defined, described, approach > to getting the OpenGL mess cleaned up. The issues should be enumerated, > the recommended approach described & discussed, and then we can each see > what we can do to help get it implemented. > ------------------------------------------------------------------------------ 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
