A rant it may be, but, accurate. Debug statements should never be made from a
‘production’ application, and your code added a LOT to what was already
polluting system logs.
As to what I claim my Mac has, the nice thing about Macs is you don’t have to
‘claim’. It’s very well documented. Here is one such page:
http://renderingpipeline.com/2012/06/mac-opengl-capabilities/
<http://renderingpipeline.com/2012/06/mac-opengl-capabilities/> . You also
don’t have to worry as to if a user has updated their driver, or is using the
correct driver. Not an issue on a Mac.
The current trunk reports that my machine is using 2.1 & GLSL 1.2, and then
states this is not sufficient, and to upgrade my hardware and/or update my
driver. This is clearly a defect. There really is no interpretation. This
machine is a MacBook Pro (Retina, Mid 2012), and all Macs made in a very long
time have supported - via driver - at least GL 3.2 which would be GLSL 3.2.
I’ve created a branch where I specify the 4.2 driver, and then all of the
shaders fail to compile, crashing the app. The #version XXX first line seems
to be a requirement. So I added the #version line, and changed the shaders so
that they compile, but, not the app crashes for something not in our code; it
seems to be in Qt, and when Alex tries this branch, his machine does not crash,
but, just doesn’t render correctly.
I’m more than will to try & solve this issue, but, as being largely ignorant
of GL, and what exactly needs to be done to configure the Qt GL subsystem.
> On Dec 1, 2014, at 6:12 AM, Georg Zotti <georg.zo...@univie.ac.at
> <mailto:georg.zo...@univie.ac.at>> wrote:
>
> 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
> <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
>> <mailto: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
> <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
