“2010: Big year for OpenGL”
Here is a detailed presentation (113 slides) done by Mark Kilgard on OpenGL during the GTC 2010. He covers all important points such as OpenGL 3, OpenGL 4, interoperability (with Direct3D, CUDA), double precision in OpenGL shaders (dmat4, dvec4, etc.), tessellation, features of OpenGL 4.1 (separate shader objects, viewport array, OpenGL ES compatibility, binary shaders, 64-bit vertex attributes, shader precision) and a word about OpenGL deprecation.
A must-read presentation for all OpenGL developers!
OpenGL version for NVIDIA GPUs
Double precision in OpenGL shaders
OpenGL deprecation: best advice for real developers 😉
NVIDIA’s Position on OpenGL deprecation:
Best advice: Overwhelming majority of deprecated features are fully hardware-accelerated by NVIDIA GPUs and their drivers so take advantage of them—they aren’t going away. Think of these features as what you lack in Direct3D
Direct3D / OpenGL interop: you can use resources created by Direct3D in OpenGL. Better: Direct3D and OpenGL can do rendering
to the same render target:
D3D and GL rendering to the same render target!
This will be good for mixing Direct2D and WebGL in Firefox.
So… what’s up with Mark’s desperate crusade against core profile and deprecation? o_O
Based on some years of enterprise-level software development experience sticking to compatibility profile will mean one thing on the long run: headache. As long as you keep reporting to your managers that “XY code part / feature / whatnot is reusable”, you’ll be forced to reuse it – even if it’s old, slow, crappy, optimized for old hardware, [insert your random coding nightmare here].
If you’ve given the choice to either stick to compatibility or go with a totally new way, you should carefully evalutate and sometimes you have to draw a line and say “we should start with a clear page here”.
Imho compatibility profile is what its name says: a chance to maintain compatibility, nothing more. Promoting it generally without a real reason (e.g. when you start a totally new project, there’s no old code to reuse) looks very weird to me…
Also, one more thing… “It may go slower because blahblahblah…” Say what? Who on Earth does capability checks during render time? What kind of argument is that? o_O
“Best advice: Overwhelming majority of deprecated features are fully hardware-accelerated by NVIDIA GPUs and their drivers so take advantage of them—they aren’t going away. Think of these features as what you lack in Direct3D”
There goes nVidia PR BS again. (Please note: i’ve been using nVidia cards since i replaced my S3 Savage4, so i’m not an ATi fanboy, etc!)
Talking in analogues… They want to promote a new sport car (nVidia OpenGL) by advertising that they added mounts to the rear bumper to make you able to have it pulled by horses? Is this make BMWs (DX) crap because they come without such mounts?
Jeez… calling outdated functionality a “feature”?
Dear Mark! OpenGL is steadily closing the gap between itself and DX – you don’t need to be _that_ desperate to promote OpenGL. 🙂
But anyway, following that logic, we could say “let’s install MS-DOS on 4core rigs too and let’s start developing 8bit software for compatibility’s sake on them, so we could reuse asm code written in the 70s”! 🙂
WTB edit… “written in the 80s…” but whatever, you get the point i guess 🙂
The old immediate API is nearly essential for a lot of pipeline tools and for prototyping. I’m glad they are leaving it in. They would have had a nerd revolution on their hands.
It is slow, but it’s by far the fastest way to get anything rendering. Very easy to add overlays, or ‘extra’ rendering data for illustration or manipulation purposes.
And for prototyping (even for prototyping shaders) it’s perfect because it uses identical shader functionality.
Most people don’t use OpenGL for enterprise software. Your parallels don’t really apply.
Not really apply? Well, ok, let’s forget CAD systems and everything else that uses hw 3D on systems w/o D3D support – THEN they won’t really apply indeed. 😉
Also, you’ve totally misunderstood my point… I was talking about the fact that Mark calls old outdated stuff “FEATURES” that are missing from DirectX. If that would be anything close to truth, then it’d be OpenGL that dominates the PC market, not DirectX – and developers all around the world would consider D3D clumsy as hell. But strangely, users of D3D could live without that for years. How it is possible? :O
If you want stuff like d3dBegin(), d3dEnd(), etc – what on Earth is preventing you to implement that as an additional layer, in form of a library for example? Nothing. Yet, nobody freakin does it – if the guy would be right, there should be tons of GPL libraries out there that are implementing OpenGL fixed-function style methods for DirectX, to make up for the MISSING (sic!) feature.
It’s not missing – people doesn’t even care about it!
About prototyping shaders and stuff…. Yeah, i understand you. Drawing a rotating cube using vertex arrays IS really hard, right? Oh wait… actually by using vertex arrays, etc it’s in fact easier to implement a very simple model loader / renderer than with fixed function.
Finally…
“And for prototyping (even for prototyping shaders) it’s perfect because it uses identical shader functionality.”
I don’t even understand this. So, you want to prototype shaders with shaders turned off ( = identical shader functionality ?!) If you turn them on, it’s barely fixed function anymore, even if you still stick to glBegin()/glEnd().
You are right. I decided to resign from my job. I’ll recommend Kilgard to do the same.
Ah, no, no, don’t do that… the situation is not that bad… yet 🙂 He just made a statement that caused most OpenGL developers smile – it’s not a bad thing after all 🙂 Oh, and not too long ago he basically called all other vendors a bunch idiots, who failed to implement fixed function (!) properly for a decade or more. Erm… but that’s ok, umm… right?
Too bad i still remember the time when his words inspired me to write my thesis….