OpenGL in 2014

http://www.tomdalling.com/blog/modern-opengl/opengl-in-2014/

by ingve • 12 years ago

284 115 12 years ago

The saying is that total rewrites are always a bad idea. It'll be interesting to see if this one would be an exception to the rule.

IshKebab• 12 years ago

It's not a rule though. Total rewrites are often not a good idea, but sometimes they are.

tormeh2• 12 years ago

For an API with 20 years of cruft? Rewriting is the only option.

srcmap• 12 years ago

Unfortunately, it also means GL has 20 yearly of usage history and large numbers of app that using it.

Rewriting those will be much more harder. A lof of them probably not open source.

lucb1e• 12 years ago

The article gives the age as only argument for why it carries all that cruft, but it can never be the only factor. If it were, the 23 year old Linux kernel project would be rotten by now, especially with the 31 year old GNU toolkit.

Sure I understand that there might be some stuff that should be deprecated (much like with HTML elements, the old stuff can be supported while newer projects use newer and better stuff), but rewriting from the ground up also means that you have to re-educate every developer out there. They might as well go and release for Windows instead since they probably have some experience with DirectX too.

Rewriting something that many people use is a bad idea, especially when there are well-funded competitors trying to get developers onto their own platforms.

diltonm• 12 years ago

I don't do 3D programming but have benefited as a happy Steam customer from the great games on Linux now. Having said that, it's generally a bad idea to re-write software with such a massive customer base on the basis of age. The term cruft doesn't qualify this notion. Refine, update sure but re-writing seems like a major overreaction.

Tuna-Fish• 12 years ago

The way I've heard it is: "Total rewrites are always a bad idea. Sometimes they are necessary."

z303• 12 years ago

Well OpenGL exists in the first place as cleaned up version of IrisGL (it originally was going to be IrisGL 5)

Dylan16807• 12 years ago

This is a new API, not a new codebase. New APIs happen all the time.

fsloth• 12 years ago

That saying is wrong. Total rewrites for the wrong reasons are a bad idea. Total rewrites for the right reasons and with _a right team_ can be great (i.e. better abstractions, better understood domain requirements which can lead to a more simple, better codebase, enable features that were not feasible before, and so on). Succintly: If the theory of the existing system is still understood well enough and the team understands the domain requirements and has experience of implementing similar systems then a rewrite can be a great idea (ref Naur: 'Programming as theory building' on what the theory of the system means as a concept and what are it's implications). For specific businesses, total rewrites can be startup-level risky and should be done due to specific domain requirements. I think this is usually what is meant by the 'bad idea' meme. Joel Spolsky wrote of this at some point and gave example of Netscape's rewrite attempt. His advice of "don't do it" was highly context dependent, though.

When we discuss of creating a new industry standard API, we are not discussing of a single rewrite. There are a few typical patterns how these are done: 'fostering' an existing tech stack under a public institution or developing the API publicly.The public API development usually consists of two parts - agreeing on the theory of the API and implementing one or more reference implementations of the said API at the same time by member institutions.

I'm not sure how to gauge the risk of this public API development. There are costs for member organisations but usually they are insignificant when compared to the size of an institution. There is usually no established product whose feature development and support stagnates because of this but rather the development is done to facilitate potential future products and features. Of course, the API adoption can fail (ref. for example OpenVG) but that fait can befall any new development for any number of reasons.

BadassFractal2• 12 years ago

Very informative, thanks for sharing that.

maaaats• 12 years ago

We need OpenGL as an alternative. What would Direct3D have been today without competition? But at the same time, GL is such a PITA to use directly that I don't bother without some middleware abstracting it away.

pjmlp15• 12 years ago

At the same level as the game console APIs.

You don't get OpenGL on those.

shmerl23• 12 years ago

There is no reason not to have OpenGL there, besides the jerkiness of console manufacturers. Hopefully Steam Machines can put an end to such situation.

cobalt• 12 years ago

ps3 had opengl available, and the Wii and Wii U use OpenGL. I don't know about the ps4.

Note, the xboxs use a modified version of DirectX which is more like mantle/dx12 (low overhead)

pjmlp15• 12 years ago

Now they just have to create ONE single API, instead of forcing everyone to write multiple code paths to target the various flavours, extensions and drivers workarounds.

Specific graphics APIs only matters when graphics middleware is not an option.

Which OpenGL always requires. Since the standard leaves out how image/shader/texture/fonts/GUI/math are handled.

I think the commoditization of engines will be the second coming of the OpenGL 2.0 - 3.0 stagnation, if they don't improve on these areas.

sjtrny• 12 years ago

OpenGL has support for: image/shader/texture/. The standard is quite clear about how these are handled. Anyway the trend (and demand from games programmers) is away from more features and towards a simplified and lower level API.

pjmlp15• 12 years ago

So in which section are APIs for loading defined?

I am having some problems locating the page.

fulafel• 12 years ago

On Linux you could in principle use the lower level hardware specific command issuing APIs as well. Mesa is not a privileged library.

bhouston• 12 years ago

Great article, thank you! Any news as to when we will get a WebGLNext?

jsheard• 12 years ago

We're still waiting for WebGL 2.0 to be finished, nevermind widely implemented, and that's based on a GLES version released two years ago rather than one that doesn't exist yet. Don't hold your breath.

Stolpe• 12 years ago

So basically, "OpenGL in 2015" will be great!

_random_• 12 years ago

Whoever doesn't force me to use C/C++ or JavaScript.

zerebubuth• 12 years ago

OpenGL might well be the "only truly cross-platform option", but it seems to me that, for games or mobile app development, getting stuff drawn on screen is only part of the problem. The rest is about doing so with the minimum use of cycles - either for better frame rates or better battery life. I can easily imagine that this is a classic 80/20 problem, with the 20% that takes 80% of the time being adequate ("butter smooth") performance.

So, given that the capabilities of the graphics hardware can vary a lot, how closely can a single, unified API like glnext approach optimal use of the hardware? And without the kinds of platform-specific code paths which are necessary under current OpenGL?

Narishma3• 12 years ago

As long as there are multiple different GPUs around, there will always be a need for multiple code paths if you want to get good use of those GPUs, whether you use the same API or not.

lloeki• 12 years ago

Having a single, unified, inefficient base code path that you later optimise at hot points is invaluable to validate non-performance (i.e most) parts of your game.

darkmighty• 12 years ago

The idea isn't to completely eliminate cross platform rewriting (which may sacrifice efficiency), but to make it minimal (and flexible).

frozenport• 12 years ago

We all got messed up with the transition to OpenGL 4 and now we are gonna have another OpenGL? I don't see OpenGL getting out of this funk until the language you learn today will be useful tommrow. Perhaps, a new API is a step in the right direction but things are gonna hurt bad bad for years to come, especially when OEMs don't support the API.

sheng• 12 years ago

All the whining and complaining makes me wondering how anyone was able to write something with OpenGL at all. This is fascinating because a great amount of people were actually able to write awesome Games and Applications with this API.

Look at the whole lot of mobile devices. I have no numbers to base this statement on but I would be bold enough to claim that OpenGL is thanks to the multiplatform ability by far the most successful graphics API out there. The set of devices that brings some or another form of OpenGL support outnumbers other graphics platforms. This alone is a huge accomplishment. Heck, even Minecraft was able to run on PowerPC systems until they pushed the java version supported[1].

But now I need to look at the link and have to admit that the criticism is still correct. The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game. This was always the case. This is why we always had an engine, a framework to built on.

But to say that it all is a huge pile of shit is a little bit harsh …

[1] https://help.mojang.com/customer/portal/articles/884921-mine...

ekr• 12 years ago

The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game.

OpenGL is a graphics library (and a rather low-level one too), so it has very little to do with games. It's only a specification for the wrapper above the gpu hardware.

pjmlp15• 12 years ago

Except other APIs offer what in OpenGL requires an engine/framework.

- Font loading

- Texture loading

- Shader loading

- Math library

- Geometry loading

- Meshes

- Integration with the OS UI

- Debugging capabilities

flohofwoe2• 12 years ago

What other APIs would that be which offer this functionality? In D3D this used to be offloaded into a separate D3DX API, but AFAIK this is no longer supported in Windows8 (at least in the WinRT API) and has been moved into separate mostly personal projects (e.g. http://directxtex.codeplex.com/). A 3D rendering API should only be concerned about efficient 3D rendering and not burden itself with specific resource file formats. For OpenGL there's plenty of libraries to choose from, for instance:

- glm for math (http://glm.g-truc.net/0.9.5/index.html)

- gli for texture loading (http://gli.g-truc.net/0.5.1/index.html)

- assimp for general asset loading: http://assimp.sourceforge.net/index.html

- the STB headers (not OpenGL specific): https://github.com/nothings/stb

- GLFW as window system glue and input wrapper

- ...and more which I am not aware of or forgot to list

GPU vendors also have SDKs and especially debugging tools (e.g. NVIDIA nSight which integrates into VStudio). It's not in one place like in DirectX, but on the other hand, the OpenGL world has a lot more platforms and usage scenarios to cover then D3D or the various new-style APIs like Metal or Mantle (these are the actual motivation for OpenGL-Next, reducing overhead even when this means a lower-level API which is even more focuses and harder to use then before).

overgard3• 12 years ago

Well by that logic, IE is a great browser because a lot of people got some amazing applications to run on it despite the fact that it was a nightmare to develop for...

OpenGL is almost like the IE of graphics development. You usually have to support it because it's so ubiquitous, but it constantly makes you want to tear out your hair because it does so many unexpected things and you have to memorize 5000 little caveats.

twelvechairs• 12 years ago

What OpenGL does is hard - to make things worth fast across multiple platforms with backward compatibility. Not like IE which was/is stagnant because of big company sluggishness/exceptionalism, but because its open source trying to do a huge amount with limited resources. There are always higher level platforms if you want something easier to work with, but you sacrifice a little speed.

nightski• 12 years ago

Wasn't IE the first browser to introduce Ajax?

EpicEng4• 12 years ago

Like javascript is an awesome programming language because it is so widely used? Oh, wait...

shmerl23• 12 years ago

Is there any ETA for OpenGL-next?

fizixer• 12 years ago

It seems no one has mentioned the long peaks fiasco yet, which is an important part of understanding OpenGL history and the committee(s) in charge of the standard:

http://en.wikipedia.org/wiki/OpenGL#Longs_Peak_and_OpenGL_3....

TL;DR: This is not the first time people are pissed at OpenGL. Last time when industry, developers, etc were sick and tired, around 2006-2007, and it was decided to do something about the API, an effort was initiated. Once the work was close to finishing, those who had seen the glimpse of this yet-to-be-released API were excited and were eagerly waiting for the release. Then the OpenGL committee vanished from the scene for a year or so, and when it re-appeared, it released the same old shitty API with a handful of function calls on top of that.

c3d• 12 years ago

The multiplicity of APIs demonstrates that the problem is hard. The needs of game developers pull the APIs in a specific direction. And these requirements must be addressed, because the games market is huge and pushes the envelope.

But other users may have different needs. OpenGL is used by games, but not just games. For example, at Taodyne, we use OpenGL for real-time 3D rendering of business information on glasses-free 3D screens. I can tell you that my pet peeves with OpenGL have nothing to do with what's being described in any of the articles.

Some of the top issues I face include 3D font rendering (way too many polygons), multi-view videos (e.g. tiled videos, which push texture size limites, or multi-stream videos, that bring a whole bag of threading issues), large numbers of large textures without the ability to manually optimise them (e.g. 12G of textures in one use case).

Heck, even the basic shader that combines 5, 8 or 9 views into one multiscopic layout for a lenticular display makes a laptop run hot for a mere HD display, and requires a rather beefy card if you want to have any bandwidth left for something else while driving a 4K display.

Many of these scenarios have to do with limitations of textures sizes, efficient ways to deal with complex shapes and huge polygon counts that you can't easily reduce, very specific problems with aliasing and smoothing when you deal with individual RGB subpixels, etc.

Of course, multiscopic displays are not exactly core business right now, so nobody cares that targeting them efficiently is next to impossible with current APIs.

electrograv• 12 years ago

Sure, the problem is hard. But so are most problems worth solving. That it's hard doesn't mean it's impossible or excuse bad solutions; Direct3D actually does an extremely good job at it, in fact.

If you've not used modern Direct3D, it's hard to concisely explain how much better it solves this problem than OpenGL. It's just a cleaner, more elegant, faster API (of course, I know this wasn't always the case, but we're talking about now).

Many of the "non-game" problems you mention really have nothing to do with the API and should be solved by third party libraries or the OS. Text rendering is not a GPU feature so don't expect a graphics API to treat it as such. The problems game developers find in a 3D API affect everyone, because at its core the 3D API is just our way of talking to the GPU.

The main complaints from "non-game" applications like this are either common to everyone (texture, render target limits), or application specific things that have absolutely nothing to do with the GPU (like text rendering) and have no place in a low level GPU API.

I know it would make your life easier if the API was more like a library with exactly your use cases already implemented, but that's simply not the role of a hardware API.

P.S. You probably shouldn't be using polygons for font rendering. Nobody does it this way in practice (except rare cases perhaps). But this is another discussion; feel free to message me privately and I'd be glad to provide more info on best practices.

shurcooL2• 12 years ago

My current approach is to use Go and target WebGL as the lowest common denominator, but with OpenGL (and/or OpenGL ES) backends as well.

That way graphics code written once can run on OS X, Linux, Windows, browser (including iOS).

ndesaulniers• 12 years ago

How do you target WebGL with Go? Is it possible to cross compile Go to JS?

graetzer• 12 years ago

It seems there is a cross compiler for Go https://github.com/gopherjs/gopherjs There are also bindings for WebGL https://github.com/gopherjs/webgl

shurcooL2• 12 years ago

As graetzer said, I use GopherJS and WebGL bindings.

For a simple example, see https://github.com/shurcooL/play/commit/cd45204c1b2d89062255....

illumen• 12 years ago

WebGL

OpenGL is now available to more people than ever. By an exponential amount.

It is supported by all major browsers. From IE, to Firefox, to Chrome, to Android, to iOS, and more.

pjmlp15• 12 years ago

... Android, to iOS ...

On iOS, only starting with iOS 8

On Android, only with Firefox. OEM modified browsers don't do it. Chrome only enables it in specific devices.

OpenGL in 2014

Related Stories