OpenGL 4.2 Specification Published With GLSL 4.20

[mirv]

Again, nVidia provides drivers at launch and also adds the features which are possible for older hardware, such as ARB_conservative_depth which would allow more performance optimization.

I haven't reviewed the new specification yet. But several of the new features would allow more tweaking and performance, and compression in memory which is a limitation for graphics cards.

It still lacks one feature I need though, an effective way to upload data and preferly geometry without traditional GL-calls. I would love if I could just exchange some of the vertex data and just use one glDraw-call to render it all, and program the pipeline fetch data itself and choose which fragments to process. It's rumored that Kepler will feature the ability to access system memory directly from the GPU, and this might be used to achieve what I want.

And of course the open source drivers are still lagging behind, and does not yet offer support for modern OpenGL specifications. Some argue that many of the components of OpenGL 3.0 is there, but the most important one, shading, is still not complete.


What kind of multithreading do you want?
OpenGL supports multiple rendering contexts and shared contexts, handling is up to the driver and window system. But still, as far as I can see, no one of the popular toolkits supports this, such as GLUT, SDL, glfw etc.

But you'll have to remember that the driver will still just do one task at a time, you you'll only achieve a queue of tasks.

Documentation is not a large issue. Samples could be much better however, almost all samples are outdated and irrelevant today. Khronos should provide samples exposing all features. I hope nVidia's new SDK will be ready soon. But still, I think the lack of a decent official OpenGL library/toolkit is a larger problem. I've had to make my own to satisfy my own needs.

OpenGL actually has support for debugging messages.

Not entirely sure if it's what you mean, but if you want a gui toolkit with multiple and shared rendering contexts, look up fox. Takes a little tweaking (for now - and it's really not difficult to do) for opengl3 contexts, but it works.
Interesting thing about the multithreading with directx - it's not hardware supported at all. So people can make something similar for OpenGL, they just have to roll it for themselves. I'm in two minds about that - on the one hand, sure, it might be nice. On the other, OpenGL has always been closer to the hardware than directx, so I'm thinking that it belongs in the domain of roll it for yourself. Most games do this implicitly anyway - threading to build a list of what to draw, then process and render the list.
If you want samples (yeah, Khronos really should be doing that), I heartily recommend www.g-truc.net - the guy there provides quite an extensive set that's well worth checking out.

[efikkan]

not only nvidias Kepler
also the r900/hd8000 will bring the same ram access system as the cpu.
i think this will be a DX12/openGL5 feature.
means all next gen GPUs will have this feature.

Yes, of course AMD will provide similar features in their next generation.

But I'm not aware of any other major new features, and I've seen a roadmap displaying "DirectX 11.1" along with Windows 8, so I guess this might end up as DirectX 11.1 and OpenGL 4.3, but I'm not sure. DirectX 12/ OpenGL 5 would make some sense, and people would love it for marketing.

Not entirely sure if it's what you mean, but if you want a gui toolkit with multiple and shared rendering contexts, <cut>

Thanks, but I don't need a GUI toolkit for that. My own library/loader currently supports separating OpenGL calls in one separate thread, so the I/O and window system does not affect the performance.

Interesting thing about the multithreading with directx - it's not hardware supported at all. So people can make something similar for OpenGL, they just have to roll it for themselves.

My point exactly.

I'm in two minds about that - on the one hand, sure, it might be nice. On the other, OpenGL has always been closer to the hardware than directx, so I'm thinking that it belongs in the domain of roll it for yourself. Most games do this implicitly anyway - threading to build a list of what to draw, then process and render the list.
If you want samples (yeah, Khronos really should be doing that)

Agree. Perhaps one day when the hardware has changed.

I heartily recommend www.g-truc.net - the guy there provides quite an extensive set that's well worth checking out.

Yes, I'm aware of that website, and it's very good.

[Yfrwlf]

I have to agree. While it sucks that we still don't have OpenGL 3.2 support on the FOSS drivers, we're a heck of a lot closer to that now than we were. I don't imagine that it'll be too terribly much longer before the FOSS drivers catch up (save for the patent problems, of course), and once that happens it should be relatively easy to stay caught up.

Who cares about U.S. patent B.S., it needs to be ignored/skirted, just give users easy access to install it after distro installation in case they do live in a stupid country like the U.S..

[plonoma]

The problem is that being sued is kinda hard to ignore.

If you have a solution for that, it would really help if you would tell everyone your solution.

Most patents aren't confined to the U.S.
Many countries in Asia and Europe recognize U.S. patents.

[DMJC]

I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD. All the platforms that are currently obscure/crap to do 3D on will have ATi/NVIDIA/Intel 3d graphics support. The Open Source drivers are moving in the right direction, and have the correct architecture under way. Criticism at this point is stupid and useless. It's like criticising someone for being unemployed when they have already filled out job applications and have done everything they can to get work. It's not like they can make a company get back to them sooner or hire them any quicker. By the same token it's not like Nouveau or the open Radeon projects can make their drivers fall out of the sky magically faster. The criticisms are silly. You want to complain about something? complain about desktop coherency, about the gnome3/unity debacle. Or about Linux not using cocoa like Apple does. Complaining about a real project with real developers busting their asses off to get the results people need is a silly pointless exercise.

[FireBurn]

If you look at GL3.txt then you'll see most of 3.x has been completed, even some of 4.x has been started

[Yfrwlf]

The problem is that being sued is kinda hard to ignore.

If you have a solution for that, it would really help if you would tell everyone your solution.

Most patents aren't confined to the U.S.
Many countries in Asia and Europe recognize U.S. patents.

It's called hosting the information in a country that isn't retarded.

[pingufunkybeat]

I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD.

Not really.

First the DRM/KMS/GEM/TTM bits of the Linux kernel need to be ported over to each one of those kernels. That provides the functionality that Gallium3d (and every classic Mesa driver which can do OpenGL > 1.5) needs to function.

The OpenGL implementation itself (Mesa) is shared, however.

And that's quite a bit of work.

[Jedibeeftrix]

Where we might have better luck is with OpenGL ES. People actually care about that API and are using it heavily on the new "hot" market, and backwards compatibility isn't nearly as important in the phone market. Maybe we can get a GL ES 3 that changes the API into a more modern alternative, and then the desktop can follow along and start using that instead of the old GL.

OpenGL ES Halti?

[Prescience500]

This is such a great idea. We should be able to use the low-level hardware access provided by Gallium3d to build a reference implementation of this nebulous new API as a G3D state tracker! Ideally the state tracker should be written with as little hardware-specific binding as possible, and version 1.0 should have the ability to reliably report on hardware capabilities, software emulated capabilities, and completely unsupported capabilities, with a well-defined interface that doesn't involve any guesswork or string parsing, and uses an easy-to-understand object model with predictable semantics, common computing terminology used as much as possible (avoiding graphics domain-specific technical terms unless they are completely unavoidable), and with a design goal of minimizing the amount of work that would be required of an engine author. Almost to the point that actually "writing" a 3d engine on top of this API would be a mimicry of the API itself. Basically, you'd get a low-level 3d engine as a Gallium3d state tracker, but still with enough flexibility to do crazy things like portal effects and non-3d geometries.

The gallium3d infrastructure may not be the end-all of APIs, but it is the best hardware-independent 3d graphics API we have in the free world right now. And it's only on version 0.4; I am sure it will improve. But what's the use of improving it if the end-user API on top of it is the culprit of most of the semantic mismatch you see?

If this was done, wouldn't that mean that application developers would have to target the code for it and that the OpenGL apps not work with such drivers? Also, apps that use such graphics wouldn't work with OpenGL drivers, right?