The correct way to prevent logging is NOT with #ifdef; it’s with proper logging,
The graphics driver you link to is for CUDA, not for system graphics cards.
Those drivers are NOT user upgradeable (without an Apple release).
The app seems to work if I discount the warning message. I’ve not looked
around it overly much.
> On Dec 1, 2014, at 12:18 PM, Georg Zotti <georg.zo...@univie.ac.at> wrote:
>
>
> On Mo, 1.12.2014, 15:28, Timothy Reaves wrote:
>> 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.
>
> If you prefer an empty logfile, please #ifndef MAC_OSX away all
> diagnostics and warnings. These are a few lines of extra messages, not
> wrong initialisations.
>
> I ask again: Does current trunk render correctly or not after you have
> clicked away ("ignored") the warning panel? I am waiting for your simple
> yes or no answer for days now. If all looks OK, the tests and warnings can
> be removed from a Mac build.
>
> I did not break anything, but try to make life easier for the team of
> currently two regular Launchpad bug report referees, at the incredible
> added burden of up to about four extra log lines on a *working* system,
> intended to be visible in a few test builds before 0.13.2. And yes, 2-4 of
> these can hopefully go away when string parsing is confirmed to work in
> all cases, but I don't know how I should know how Intel and AMD (formerly
> ATI) formatted their driver strings since 2006 (?) on all subvariants of
> supported systems, so I am in fact expecting some string parsing errors by
> self-assembled hardware and self-compiled operating systems unknown to me,
> used by other people unknown to me, on other continents. If the program
> tells the user what to do not only in a hidden logfile which some bug
> reporters have not even found yet, but in an alert panel, we will
> hopefully not get zillions more boring redundant bug report from
> decade-old systems. This is an attempt to find out what is going on here
> on all other operating systems, and ultimately find out what is really the
> culprit that the GLSL1.10 shaders cause problems even for GLSL1.20 capable
> systems.
>
>
>> 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.
>
> Great, OpenGL3.2, not 4. Then why does the call glGetString(GL_VERSION)
> deliver an answer from your OpenGL driver that basically says "This driver
> supports OpenGL 2.1"? Such a message also appears on e.g. a Windows system
> when drivers are old. The solution on a Windows or Linux or Ubuntu or
> FreeBSD (or whatnot) system is to download and install new drivers, a.k.a.
> update drivers, and then it reports OpenGL3 or better at this query if the
> hardware is capable, and works. I don't know if I should be surprised if
> Apple systems cannot be updated in a similar way, or if you just buy a new
> Apple. On the other hand why would there be e.g.
> http://www.macupdate.com/app/mac/49241/quadro-geforce-os-x-drivers
>
>
> It may then be a Mac specific issue not found on the rest of computer
> systems, which has been reported by you in a very unfriendly way not
> earlier than last Friday.
>
>
>> 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 ask again: Does current trunk RENDER correctly or not after you have
> CLICKED AWAY the warning panel? I am waiting for your simple yes or no
> answer for days now. If stars and planets look OK, the tests and warnings
> can and should be removed from a Mac build, sure.
>
> But the question remains why does glGetString(GL_VERSION) deliver an
> answer from your alleged OpenGL3.2 system that says OpenGL2.1? This is a
> call that I thought was independent from Qt and reports a system
> component. http://www.macupdate.com/app/mac/17087/opengl-extensions-viewer
> would give an independent diagnostic.
>
>
>
>> 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.
>
> As I have already written, it is a requirement for code starting with GLSL
> 1.20. If the line is missing, it's compiled as GLSL1.10 for OpenGL, or as
> GLSL ES 1.00 for OpenGL ES 2.00.
>
> See these PDFs from the Khronos site:
> The OpenGL® Shading Language
> The OpenGL® ES Shading Language
>
>
>> 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.
>
> Does specifying version 4.2 work with the drivers reported as 3.2 on that
> website? I guess not. Have you tested what kind of context/version/... you
> received later?
>
> When you indeed want to use some higher version like 3.2, there is this
> relevant issue about initializeOpenGLfunctions() found in this year's Qt
> blogs and docs. Stellarium currently runs circles around not deriving
> rendering classes from QOpenGLFunctions as Qt recommends. Staying at
> OpenGL2.1/OpenGL ES2.0 level is as I can see it an attempt to keep
> compatibility with as many systems as possible as long as 3.2
> functionality is not required. However the last months have shown that
> also ANGLEs don't come as ultimate saviours for oldfashioned Windows
> hardware (oldfashioned, not old. Yes my 2010 netbook has only lousy
> OpenGL1.4), and systems not reporting OpenGL3/GLSL1.30/ps_3_0 in whichever
> init strings are queried, are simply doomed to fail, at least on non-MacOS
> X systems.
>
> The OpenGL initialisation can be improved, no doubt. Qt5.4 brings another
> round of changes and deprecates currently used classes. Somebody hopefully
> finds time and has knowledge to put it all right again upto 5.4. Fighting
> against testing and improving diagnostics is however no improvement
> towards understanding what works or does not work.
>
> BTW, this seems to be related: http://qt-project.org/forums/viewthread/20424
>
> And now, apply this...
>
> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ 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
