

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

======
c3d
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
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.

------
fizixer
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....](http://en.wikipedia.org/wiki/OpenGL#Longs_Peak_and_OpenGL_3.0_controversy)

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.

------
zerebubuth
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?

~~~
Narishma
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
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.

~~~
Narishma
I didn't say otherwise.

------
sheng
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...](https://help.mojang.com/customer/portal/articles/884921-minecraft-
java-5-and-powerpc-support)

~~~
overgard
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
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.

~~~
overgard
> What OpenGL does is hard

If you think what browsers do is easy... :-)

Here's the thing though: most of what OpenGL screws up is the not-hard stuff.
Here are the main things wrong with OpenGL right now:

* Everything operates on and modifies implicit global state, especially with the various "bind" patterns (direct state access will help a lot with this). Even a first year CS student knows global state is bad. It was sort of acceptable-if-ugly back when the fixed function pipeline was the thing, but for almost the last 10 years that's been deprecated, and with how you program a GPU now that global state and bind patterns is ridiculous.

* Error handling is unfriendly and confusing and slow. It's very easy to accidentally send in a bad parameter to a function, have OpenGL silently ignore it, only for something to blow up in your program in a completely different module because that error went silently unchecked. This is just bad. Not only that, but glGetError rarely gives you any useful information. Why can't it at least tell me what function failed, and which parameter/value it was that made it fail? A lot of times you'll see an error in a complex function like glTexImage2d that has a ton of possible parameter combinations for "invalid value". Well, which one is invalid? What inputs would be valid? The driver knows, so why can't it tell me?

> 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.

Have you looked at the companies that comprise the khronos group? They're not
exactly poor. The problem isn't resources, it's bad design by committee.

~~~
hornetblack
> with the various "bind" patterns

Nvidia have been pushing for bindless graphics.

[http://developer.download.nvidia.com/opengl/tutorials/bindle...](http://developer.download.nvidia.com/opengl/tutorials/bindless_graphics.pdf)

------
pjmlp
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
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.

~~~
pjmlp
So in which section are APIs for loading defined?

I am having some problems locating the page.

~~~
wlievens
That would be an API for asset management. OpenGL doesn't do that. It does do
textures and shaders though.

~~~
pjmlp
Which was my point, other graphics APIs do offer such support.

~~~
bsenftner
That's not the job of a graphics API. It's a convenience utility that is not
really feasible for OpenGL because it runs on so many platforms. You're asking
for platform specific features on a cross platform library.

~~~
pjmlp
What is platform specific about loading assets?

OpenGL is specified as a C API.

Such asset loading API could be defined just on top of ANSI C IO functions.

What about forcing every single OpenGL developer to write the same set of
shader loading/compling/linking code?

~~~
orbifold
Compared to what OpenGL has to accomplish, asset loading is orthorgonal. There
is a number texture formats that most graphics cards support natively, the
OpenGL API already exposes more than those and the Driver converts them on the
fly. It is trivial to implement a bmp loader and slightly harder to load
something like textures compressed with DXT, there are obviously third party
libraries that do that for you. There are simply too many potential texture
sources, to integrate that into an api. The same goes for 3d model loading,
there are simply too many model formats and how you organize your vertex data
is application specific anyways. The reason the shader loading / linking and
compile code has to be written by the Developer is also fairly obvious, OpenGL
does not want to support cross platform File IO and in real world projects
100s of shaders are actually dynamically linked in different combinations into
render pipelines to create desired effects, the effects themselves are often
creates in some kind of flow-based programming environment that is translated
into shaders behind the scenes. Basic shader loading/compiling/linking on the
other hand is trivial to implement.

Finally Window/Context creation is also platform specific and therefore can't
really be specified.

~~~
pjmlp
> OpenGL does not want to support cross platform File IO and in real world
> projects 100s of shaders are actually dynamically linked in different
> combinations into render pipelines to create desired effects, the effects
> themselves are often creates in some kind of flow-based programming
> environment that is translated into shaders behind the scenes.

Which other APIs support with effects, scene description files, ....

> Basic shader loading/compiling/linking on the other hand is trivial to
> implement.

Hence why every single OpenGL newbie keeps copy-pasting it from somewhere.

> Finally Window/Context creation is also platform specific and therefore
> can't really be specified.

So why did they get to the trouble of creating EGL?

------
maaaats
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.

~~~
pjmlp
At the same level as the game console APIs.

You don't get OpenGL on those.

~~~
cobalt
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)

~~~
pjmlp
> ps3 had opengl available

Again this urban legend.

PS3 had PSGL, which was OpenGL ES 1.0 using Cg as shading language.

This is quite different than OpenGL.

Wii uses GX and the Wii U uses GX2, they are modeled on OpenGL, which is also
a bit different than being OpenGL.

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

~~~
jsheard
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.

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

------
frozenport
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.

------
shurcooL
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
How do you target WebGL with Go? Is it possible to cross compile Go to JS?

~~~
graetzer
It seems there is a cross compiler for Go
[https://github.com/gopherjs/gopherjs](https://github.com/gopherjs/gopherjs)
There are also bindings for WebGL
[https://github.com/gopherjs/webgl](https://github.com/gopherjs/webgl)

------
illumen
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.

~~~
pjmlp
> ... 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.

------
BadassFractal
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.

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

~~~
lucb1e
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.

~~~
raverbashing
Yeah, but Linux is not afraid of removing cruft. Computers (and the x86-i386
arch) changed very little over the past 20 years, _even_ with the 64-bit stuff

Graphical cards evolved much more in the last 15 years.

The first Direct3D versions were also bad, but they evolved and removed cruft
and broke backwards compatibility.

------
shmerl
Is there any ETA for OpenGL-next?

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

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

