My hardware support OpenGL 5, and my driver supports 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. And then the code complains, and offers to continue. Not good.
And the driver is not user upgradable. Nor in this specific case does that
matter.
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. 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.
On Fri, Nov 28, 2014 at 4:40 PM, Georg Zotti <georg.zo...@univie.ac.at>
wrote:
> 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
>
------------------------------------------------------------------------------
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
