I’m posting this because I’m pretty sure that some nVidia guys while read it and this is actually a suggestion for the future release!
I’m soooooo but sooo feed up by some nVidia communication bad practices such as this news. I actually thing that I’m event more feed up by all this stupid websites forward this news and it’s quite a shame to read it event on OpenGL.org.
Drivers 190.56 are NOT OpenGL 3.2 drivers. It’s OpenGL 3.1 drivers with some features of OpenGL 3.2. Just like ATI drivers are … We got the same news with OpenGL 3.0 and OpenGL 3.1 releases.
I love so much lot of nVidia stuff, cards, docs, projects, I just suggest nVidia to stop fallacious communication. Sooner or later I believe, it is just going to be bad for the company reputation.
Most features have been approved the 3th of July and the 24th of july … could we actually expect a full implementation that soon?
No and that’s fine, development take time, having features as soon as possible is great and that all we could expect.
I hope pointing out this will change the balance in the debate of drivers with ATI suposed to be 6 months late over nVidia … Well that not the case even if I agree nVidia is more advanced on that topic.
Sorry, I think I’m at fault here for not understanding something.
I confess I didn’t realize the distinction between compatibility and forward-compatibile. I assumed that by not specifying forward-compatible that I got backward compatibility (as was the case <= GL 3.1).
Now I think I see the distinction:
PROFILE_MASK = COMPATIBILITY -> Backward compatibility included
FLAGS = 0 -> Deprecated but still supported APIs included
FLAGS = FORWARD_COMPAT -> Deprecated but still supported APIs killed
So for the most lax profile (include all the old stuff), you want PROFILE_MASK = COMPATIBILITY and no FLAGS = FORWARD_COMPAT. And for the most strict profile, you want PROFILE_MASK = CORE and FLAGS = FORWARD_COMPAT.
(updated) I was using the default options of PROFILE_MASK = CORE and no FLAGS = FORWARD_COMPAT, which kills backward compatibility.
Very insightful link even if I wonder why it is posted here.
“We use OpenGL SW (GDI Generic) in all our QA because at least we get the same consistent result”.
Back to my previous job we were also using the OpenGL Software drivers so be sure that at least it run … well so slowly that it could not be used …
I would say that all these releases OpenGL spec must be seen as a nightmare.
Autodesk is building long term softwares based on a really old code (probably older than 15 years for some) which must be quite horrible. That was exactly this case at my previous job so going into new features even shader was so so so long an painful.
What such software need: stability. They are not going to update their “rendering engine (mess)” for each release.
However, I believe that the main fault is on their side like it was for my previous company. “OpenGL is just an API” “Out software goal is not OpenGL / Direct3D rendering, it’s raytracing, modeling tools”. So basically, if I had a look on the code I would expect to see no OpenGL engine at all, OpenGL code everywhere in 20 000 000 lines of code.
Well, I exaggerate a bit but that the basic idea. Very complicated code to maintain leads to nothing good. I’m using 3DS Max 2010 time to time, I quite like it, but the OpenGL renderer is not a stable option, the Direct3D renderer is “ok” but doesn’t look good, the few shader effects look like hack in the code, the overall rendering is freaky slow.
Finally, I think that OpenGL is valid option for these softwares for compatibility using the fixed pipeline. I agree that Direct3D 10 would be a great platform for advanced rendering because the constrain a really strict.
I totally agree. But it seems that the new GL spec’s did not help much in driver quality and stability. And one thing drew my attention in that paper, is that GL lacks of QA. It’s the job of the API users to make sure things work, and they are left with a big Q whether the bug is on their side or the driver’s.
I’m not here criticizing the API itself, nor the IHVs who implement them. Some party should take charge of a solid GL SDK, and leave the IHVs with minimal driver implementation…like in D3D
I’d rather see Khronos investing time/money in development of conformance test suite for OpenGL.
I am always nervous when installing new drivers. Usually something gets broken with new drivers. (using NV)
We have a list of HW/drivers that works well. When user calls to support line, the first question we ask is the HW/drv.
Excellent idea indeed. It’s just, that that idea has been around for ages, but the ARB has not the resources to implement such a thing. That is why we don’t have a conformance test now and i am pretty sure, we won’t get one in the future.
It’s sad, but the fact is, that D3D IS a better option, if you can afford to only support Windows (Vista).
but per the NVidia driver release page, I need to use the old glXCreateContext() call for now since glXCreateContextAttribs doesn’t yet support PROFILE_MASK (attempting to do so generates a BadValue X error from GLX).