OpenGL 4.0 Spec Released

tbcpp writes "The Khronos Group has announced the release of the OpenGL 4.0 specification. Among the new features: two new shader stages that enable the GPU to offload geometry tessellation from the CPU; per-sample fragment shaders and programmable fragment shader input positions; drawing of data generated by OpenGL, or external APIs such as OpenCL, without CPU intervention; shader subroutines for significantly increased programming flexibility; 64-bit, double-precision, floating-point shader operations and inputs/outputs for increased rendering accuracy and quality. Khronos has also released an OpenGL 3.3 specification, together with a set of ARB extensions, to enable as much OpenGL 4.0 functionality as possible on previous-generation GPU hardware."

Comments

Patent problems still there?

[H4x0r Jim Duggan]

Any chance the patent problems of OpenGL 3 have been fixed?

Re:Patent problems still there?

[binarylarry]

It's not really a huge problem in practice.

All the major graphics IHV's provide that extension anyway. It would nice if it was in GL's core spec, but since it's included for any device that matters, it's not a practical concern.

Re:Patent problems still there?

[amorsen]

What makes you assume "software" solutions to technological problems are not patentable in the EU?

It says so right in the law... However, the European Patent Office are able to read between the lines and divine what the lawmakers REALLY meant, so they allow software patents.

So far there is (AFAIK) absolutely zero case law about software patents in the EU, so the courts haven't decided whether EPO's reading is correct. Companies seem content with doing their patent fights in the US. Why bother with dealing with a troublesome case making a precedent in the EU when the defendant is likely selling the exact same software in the US where software patents have been involved in numerous cases?

OpenGL on par with Direct3D11

[Thunderbird2k]

To give an idea to non-OpenGL developers, OpenGL 4.0 closes the feature gap with Direct3D11. If you want to use OpenGL 4.0 you need to wait a couple of weeks before drivers will be out. In case of Nvidia, the drivers will be launched together with their new GTX4*0 GPUs which are the first Nvidia GPUs with Direct3D11/OpenGL 4.0 support. AMD might release new drivers before Nvidia since their hardware is Direct3D11 capable already.

Re:OpenGL on par with Direct3D11

[binarylarry]

What I meant is loading a picture and using it as a texture.

Oh, so how does this even matter from a language/platform/execution standpoint? In the case of loading a texture from disk, you're going to be limited by IO wait anyway, which means even something like Bash would work initiating the transfer and waiting while it's finished.

Interesting. Still, you're going to need to read a model from a file or create its geometry.

Again, you're talking about IO wait, which isn't really limited by your application's execution speed anyway. I'm sure you knew that though, you seem like a very experienced and capable programmer.

Yeah, but I wouldn't advocate Java for 'real time' apps also the kind of geometry processing OpenGL requires. (which is what you'll probably be doing apart from the OpenGL triangle demo)

Your application doesn't usually "process" geometry, in any sane application you just send off a big chunk of data to the server and the OpenGL implementation handles it from there. Regardless, Java is fast, so if you're generating the geometry it's fine anyway. Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.

Please type 'java floating point' into google and check the first article

I hate to be the one to break this to you, but floating point is fraught with all types of these issues. It's not a data type to be used for any application requiring exact calculations, which is why fixed point alternatives exist.

Besides that, OpenGL is going to mangle your floats and turn them into yet another representation on the GPU server side anyway.

I mean look at SIMD with something like SSE on an x86 chip. It will also *mangle* your floating point values, chomping off lots of data and return skewed values. It's just the nature of floating point.

Re:OpenGL on par with Direct3D11

[TheRaven64]

You seem to have misunderstood how OpenGL is meant to work. It is intended to standardise existing features; that's the entire point. Individual vendors add extensions, developers test them, and the useful ones are added to the next version of the spec.

Re:OpenGL on par with Direct3D11

[Hurricane78]

Only a loser would make his goal to get on par with the competition. Because at the time when he would reach that goal, the competition would already have moved on.

I want them to put DirectX to shame! New! Revolutionary! Impressive! Putting MS in the position to catch up!
Because when MS is in that position, they are known to fuck up. (They make the same error of not trying to surpass the competition.) ^^

Design a spec, that is every graphics card designer’s, every game developer’s and every player’s wet dream!

It’s like car racing: If you concentrate on the car in front of you, you will fall back. If you stop caring for him, and concentrate on your own goals and the track in front of you, you’ll suddenly find yourself left of him, passing by. :)
(The same is true for concentrating on cars following you.)

Re:OpenGL on par with Direct3D11

[bonch]

It literally feels dirty, to go to C/C++ after having worked in Haskell.

Give me a break. C and C++ aren't going anywhere, and barely anybody is using OCaml or Haskell, especially not for OpenGL applications. You sound like another amateur Reddit poster who thinks C is hard because it has pointers. C is simple, fast, and elegant.

In the real world, outside of the buzzword-laden, blog-driven, pseudo-academic world you were spawned, C and C++ remain the dominant languages for commercial application development. That includes Objective-C on the iPhone.

Re:OpenGL on par with Direct3D11

[Forkenhoppen]

This jostling for OpenGL to jump over Direct3D in terms of features is ridiculous.

You can't have stable without the beta.

Re:Hardware support

[binarylarry]

It's most similar to D3D 11.

DirectX is a larger set of development technologies and apis (most of which has been deprecated). Direct3d is it's "direct" analog to OpenGL.

Re:DOA for anything but pro gear

[Again]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

I wouldn't be so quick to say that DirectX won. The xBox 360 is the only current generation console which uses DirectX.

Re:DOA for anything but pro gear

[aristotle-dude]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

OpenGL is used on PS3, linux and OS X. It is also used on any game in windows that is cross platform compatible where they did not bother implementing a DirectX engine. Every platform now has HID handling and you can use OpenAL if you want to have the same sound effects engine on windows, OS X and possibly linux.

Now that Valve is porting Steam and related games to OS X and consequently OpenGL, expect to see more activity surrounding OpenGL.

That's not was the Mesa devs say

[H4x0r Jim Duggan]

> it's not a practical concern.

According to the references linked from that en.swpat.org page, it seems the developers of the free software Mesa project think it's indeed a practical concern.

Re:That's not was the Mesa devs say

[binarylarry]

How many products are shipped with Mesa as an important, primary component?

If you're using OpenGL, 99% of the products are going to want real hardware acceleration, not Mesa.

Mesa is a great project though, don't get me wrong.

Re:That's not was the Mesa devs say

[TheRaven64]

Mesa is used in a lot of X.org drivers. It provides the OpenGL state tracker for Gallium3D, so it will be used a lot more in future.

Re:That's not was the Mesa devs say

[binarylarry]

Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.

The OSS offerings do not provide nearly the same level of performance, unfortunately.

So again, from a real world practical standpoint, Mesa isn't in use anyway.

Re:That's not was the Mesa devs say

[malloc]

Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.

The OSS offerings do not provide nearly the same level of performance, unfortunately.

So again, from a real world practical standpoint, Mesa isn't in use anyway.

Unless you meant to say "OpenGL 3.0" This is absolutely not accurate. Has your "real world" been isolated to workstation CAD and/or heavy gaming users? Those are the only groups where binary non-mesa drivers are used almost universally, but they are a minority. Intel, which has over half the graphics market only uses mesa. Your default Fedora and upcoming Ubuntu 10.4 installs use mesa for both amd and nvidia chips. AMD actively supports the open driver and is working to make that the main driver.

The continued development on gallium points to mesa gaining more traction. I think the trend is for binary drivers to become less and less common in the future.

-Malloc

Re:That's not was the Mesa devs say

[Kjella]

AMD actively supports the open driver and is working to make that the main driver.

They are working on an open driver yes, but they are not looking to replace the proprietary driver in the foreseeable future. For a number of reasons - not least of which is the tons of optimization work going into the main driver - they expect the open source 3D performance to top out at 60-70% of Catalyst by keeping a simple structure. That is much better than than the difference between accelerated and unaccelerated though which can be <1% of the performance.

Re:That's not was the Mesa devs say

[malloc]

But gallium and the open source drivers aren't really ready for prime time, they're theoretical. I'm talking about practicalities. Right now, the open source drivers only exist to keep X running long enough to get the proprietary drivers installed.

[emphasis mine]

Again, except for the majority of users! The default mesa drivers let you run Quake 3, composite your desktop, and do whatever 90% of desktop users want. It's only the "I want to play the latest game with max fps" and the "I'm rendering 100 million vertexes / frame in CAD" people that need to change to a binary driver.

No one is going to need S3TC compressed texture support for things like compiz anyway.

(FYI, the latest mesa actually supports S3TC this in the same way MP3 is. Too bad we have to wait till 2017 for patent expiry.)

Re:That's not was the Mesa devs say

[mojo-raisin]

Incorrect. Proprietary drivers are no longer required for Real Work.

I use the OpenSource Radeon Drivers with Mesa 7.7 to do lots of work with PyMol. It has all the performance I need, is stable and glitch free.

From what I've read, Mesa 7.8 is just around the corner, and will be even better.

Open Source Accelerated 3D has arrived.

Re:DOA for anything but pro gear

[TheRaven64]

Added to that, OpenGL ES, which is almost a direct subset of OpenGL (it adds a couple of things, but you can quite easily write code that is both valid OpenGL ES and OpenGL), is present on almost all mobile devices. If you want to write a 3D app or game that runs on a mobile phone, you use OpenGL ES. I think Wince has a DirectX implementation of some kind, but it has such a tiny market share that it's largely irrelevant.

OpenAL is also cross-platform; there's a software-only implementation that runs very nicely on Linux, *BSD, and Solaris; it's not just Windows and OS X. Creative provides OpenAL acceleration on a few other platforms, but I don't think anyone else does - there's not really much point these days in offloading sound processing, CPUs are more than fast enough.

Re:Hardware support

[tepples]

IMO OpenGL is always going to be better unless DirectX becomes more cross-platform friendly

Direct3D is already cross-platform: Windows, Xbox 360, Zune, Windows Phone 7 Series. Among these is the only video game console open to indie development.

Re:DOA for anything but pro gear

[Lunix Nutcase]

You mean other than the fact that what the PS3 and Wii run aren't really OpenGL but proprietary derivatives of OpenGL ES?

Re:Hardware support

[binarylarry]

It's like Ford's Model-T: You could order in any color you wanted, so long as that color was black.

Consoles Don't Count?

[medv4380]

Really?

Given that the PC gaming market is really a joke compared to the console market I think DirectX is really rather meaningless.

When the Top 50 selling games world wide contains only 3 PC games The Sims, World of Warcraft, and Starcraft it's time to say that DirectX for the PC is over rated.

Since the Wii and PS3 use a custom modified version of OpenGL for their hardware I'd also have to side with OpenGL as at least being relevant to professional games.

Re:DOA for anything but pro gear

[ultranova]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

DirectX is indeed widely used on Windows, since it handles more things. OpenGL handles just graphics, but is cross-platform; with SDL it's close enough to DirectX that it's often used. And of course you could use OpenGL for graphics and DirectX for everything else.

I like the current situation where the two coexist and force each other to evolve to stay competitive. It's a bit like AMD forced Intel to get off its ass and make good and cost-effective processors again. We'll see if NVidia is able to respond to ATI/AMD's challenge too; but at least we won't see similar stagnation as with 3Dfx after initial Voodoo.

The only good thing about capitalism is that competition forces companies to get off their ass and evolve. A pity it doesn't work anywhere except the tech sector.

Re:So..

[Chatterton]

OpenGL tutorial

Re:DOA for anything but pro gear

[Brian Feldman]

and you can use OpenAL if you want to have the same sound effects engine on windows

Especially Windows Vista and 7 since DirectSound acceleration doesn't exist anymore LOL

Yeah, sound processing is really quite intensive for a modern computer with some cores lying mostly unused by most video games even without sound turned on.

change to stateless API abandoned?

[Eric Smith]

3.0 was supposed to introduce a stateless API, but didn't. Now 4.0 apparently hasn't either. Have they decided that it's a bad idea, or that it's too difficult, or what?

Having the API retain state is a fundamentally bad idea. As one overview points out, "Nearly all of OpenGL state may be queried". (emphasis added)

It would be much better if there were OpenGL context objects that encapsulated the state, and were explicitly passed into API calls. I was completely dumbfounded when I first looked at API and saw that it didn't work that way.

Re:change to stateless API abandoned?

[IgnoramusMaximus]

Have they decided that it's a bad idea, or that it's too difficult, or what?

I am a bit fuzzy here on the idea of "stateless" API that deals with inherently state-oriented hardware such as GPUs with their frame buffers, pixel processors, massive texture memories and what not...

It would be much better if there were OpenGL context objects that encapsulated the state, and were explicitly passed into API calls.

So you do you expect the entire (multi-hundred megabyte sized) state of the GPU and its memory to be duplicated in system RAM and somehow auto-magically transmitted back and forth with each operation? Do elaborate.

Re:change to stateless API abandoned?

[JesseMcDonald]

I expect that the idea is that instead of calls like glClearBuffer(...) which take their context from the program's global environment, you'd have calls like glClearBuffer(context, ...). The point of this would be to make it easier for a given program to work with multiple contexts at once, e.g. for mixing render-to-texture with normal rendering. (Note: I am not an OpenGL expert, by any means.)

I'm certain no one is suggesting that the GPU become stateless, just the API.

Re:Hardware support

[tepples]

Nintendo requires a new Wii developer to have previous published commercial titles on another platform as well as a "secure office facility", a hurdle that most micro-ISVs cannot clear. 2D Boy had to pretty much cheat Nintendo in order to qualify for a Wii devkit without the overhead of having to lease an office.

Re:DOA for anything but pro gear

[javiercero]

The irony of it all is that in the tech sector, a lot of the evolution and advancement come from people who are in it because they love technology and scientific research, not just because of monetary rewards

In fact I know people who love so much what they do, they will point blank tell you they do it most definitively not for the money since they don't get paid anywhere near the amount that their time and effort would deserve.

Which sort of proves that most of the assumptions by those in love with Capitalism are at best incredibly dishonest. If people were guaranteed a relative level of stability (guaranteed housing, health care, food, and education) while being allowed to concentrate on what they love, you'd see humanity advancing by leaps and bounds. But then, the aim of Capitalism (and most other "isms") is not human advancement, but rather a closed loop cycle of concentration of capital, since that very same capital is both the means and the end.

Sorry for the tangent...

Only 4.0!

[johno.ie]

DirectX goes all the way to 11.

Mod up!

[n dot l]

I expect that the idea is that instead of calls like glClearBuffer(...) which take their context from the program's global environment, you'd have calls like glClearBuffer(context, ...). The point of this would be to make it easier for a given program to work with multiple contexts at once, e.g. for mixing render-to-texture with normal rendering. (Note: I am not an OpenGL expert, by any means.)

I'm a game developer. I work with OpenGL. This is exactly what's meant when people bitch about OpenGL being stateful. That and the selector states, which make it annoying to write libraries that target OpenGL and work together nicely.