Hacker News Reader

Comment by exDM69 | Hacker News Reader

I have to say that this is nothing short of a miracle. The OpenGL API is really hairy to implement at all, let alone making it fast. There's 20 years of accumulated legacy and design mistakes that the driver vendors need to care about. D3D, on the other hand has been re-designed on every iteration and backwards compatibility has been broken in every major release.

On the other hand, porting from D3D code, you don't touch the hairy parts of OpenGL at all because D3D is functionally quite close to the "clean parts" of GL. But there's still some software overhead to overcome. They might also be using a proprietary D3D-on-OpenGL layer, like the ones being used for some Mac ports of Windows games (edit: seems like they are not).

I hope that Steam, and gamers that use Mac and Linux in general, will push for bigger changes in OpenGL, both specs and implementations.

disclaimer: I write GPU drivers for living

View on HN

> disclaimer: I write GPU drivers for living

Is that a reason for us not to take you seriously? Feel free to disclose any connection you have with the subject but please don't disclaim responsibility for your comments. :)

Unless, of course, you want to..

(Sorry for the no-content post but I see this word used in every second thread these days and it's one of the things that might be driving me nuts.)

All I think he's doing is alerting the reader that his perspective might be skewed because of his job. In this particular instance, I think that's useful because it balances out the extra authority his comment otherwise gets from the detail he provides (also presumably from the same job).

Whilst it is dangerous to guess at what people were meaning, I understood the 'disclaimer" to mean "I do this for a living so I know what I am talking about".

So, if that is the correct interpretation then is not a disclaimer, more a disclosure. Which is what noibl was trying to educate exDM69 about.

But it is really all idle speculation until exDM69 chimes in.

Disclosure, disclaimer. Both apply. I disclose that I work in the field but it can also be a disclaimer that I have extremely skewed views because of the frustrations that years of working too closely with OpenGL can bring. English is not my native language, sorry for any confusion.

Personally I think "disclaimer" is exactly right. If you work on the drivers (or some other low-level component that's part of the general plumbing), your concerns are not always aligned with those of people writing the actual software. Therefore, if you have a complaint about something, it may be that you should be the one who has to do the hard work rather than the application writers, because making your life easier might not maximize overall happiness.

So, "disclaimer" is spot on, I believe, because application writers might like to shed a tear, but not sympathize too hard...

Dang, now you've made me look up the definition! Apparently, one should only disclaim when one wants to distance oneself from a previous claim.

Maybe it's time for OpenGL 5.0 to start from scratch, and support only the latest x86, ARM and MIPS chips. It might be the only way to catch-up with DirectX, no? Right now I'm excited about OpenGL ES 3.0 for mobiles, and what will bring to the mobile market.

> Maybe it's time for OpenGL 5.0 to start from scratch

Yes. Someone should do it. The major industry players seem to have the interest but lack the will to put in the resources it requires.

> Right now I'm excited about OpenGL ES 3.0 for mobiles

Prepare for disappointment.

If you prepare for disappointment, you're can't really be disappointed, can you?

You can always be more disappointed.

Spoken like a true OpenGL programmer. :(

I work from the proposition that we are all crazy arrogant monkeys whose main talent is the ability to construct and understand stories.

This means I am constantly really impressed by the fact that we get anything done at all.

Unfortunately, I am also a crazy arrogant monkey, so am also constantly really deeply disappointed by the fact that we haven't all got jet-packs and holiday homes on the moon yet.

Well good version of OpenGl 5.0 would be very welcome(even without complete rewrite), but history shows that ARB(Architectural Review Board) likes to shoot itself in foot[1]. Design by committee usually takes a lot of time, so rewrite would probably take forever given number of legacy OpenGL Cad applications.

Small nitpick: OpenGL would be catching up with Direct3d not with DirectX(which includes parts like input or sound that AFAIK are out of scope for OpenGL)

[1]http://programmers.stackexchange.com/questions/60544/why-do-...

edit: found HN discussion about this link: http://news.ycombinator.com/item?id=2711231

Thanks for that! I totally forgot about Fahrenheit and I was super excited about it back then and depressed when it got cancelled, ha!

They tried with OpenGL 3, but then it took them years and the plan were scrapped. ( That is when Microsoft brings DirectX 9 to the table, which is well designed and much more usable then OpenGL ). They restarted development a few years ago to clean up the mess.

The main reason why OpenGL did not get a restart were because of pressures from CAD and 3D Modelling Industry.

The cynical view is that having two standards, one consumer and one pro, lets graphics companies ship the same chips, but charge 10x as much for the pro version with a couple driver tweaks. If the consumer games were written against the pro standard (requiring pro support in the consumer cards), how would they justify the pro line?

Why is that community (CAD/3d-modelling) even sitting at the table?

These modern GPUs are very generalized hardware now. Their drivers are "simulating" all kinds of features. Its a bit like OSS vs ALSA. They should just make the GPU a standard compiler target, and offer only the bare minimum (video-mode-setting) at the driver level.

Let the game industry write/design their own API on top. Let the CAD community do the same for their usecases. I know, with Mesa, this is kind of the setup. Except mesa isnt executed by the gpu: it runs on the CPU, and from there it executes code on the GPU.

Wouldnt it be much nicer if GPUs just behaved like CPUs? They are just optimized for different types of proccesing. Thats the interesting end-game: could the CPU be optional?

GPUs still have a ton of performance-critical fixed function units, and actually recently gained a new category of fixed-function unit (tesselation). OpenCL cannot replace OpenGL or D3D.

And the CAD/DCC market gets a say because they pay 10-100x more per seat than consumers.

OpenGL ES 2.0 is close to the "clean parts" too. I think targeting that subset of the API is a great way to keep OpenGL code totally sane and manageable.

GLES2, GL3 and GL4 are the "clean parts" only, OpenGL 1.x features have been removed. But the API is still a mess and has all the design mistakes dating back to 1992.

Isn't "OpenGL - The good parts" actually called OpenGL 2.0 ES?

That's what I was thinking - it's a pretty clean subset, but since it's designed for mobile it is probably missing too many of the more advanced features desktop games tend to use. Perhaps one day OpenGL ES could supersede the desktop OpenGL...?

I'm not sure how that would happen, since by definition mobile chips and OpenGL ES need to be "leaner" and maximize efficiency, to preserve battery life, while on the PC you don't care as much about so the chips are more "bloated", and contain a lot more features, since battery life is not much of a concern. Although we may see a return to efficiency, now that laptops are overtaking PC's, but they still need to get rid of the legacy stuff first.

I think what you meant is that OpenGL ES may one day be more popular and more used than the "full OpenGL", because there are a lot more mobile devices + WebGL.

> Isn't "OpenGL - The good parts" actually called OpenGL 2.0 ES?

No, it is called the GL 4.2 core profile. GL 4+ core profile is a superset of GLES2. It does not include any of the stuff left behind from GL 1.x days.

GLES2, and Big-GL3+ have the legacy graphics features removed but the API is still horrible. More on this in my other comments in this thread.

OpenGL 2.0 ES is absolutely horrible - it's 3 generations behind on hardware capabilities even in mobile devices, for eg. even tough almost all chips on mobile support multiple render targets (MRT) I haven't seen a way to do this in ES with any extension yet, even in WebGL. MRT is some pretty basic SM3 (Direct3D 9) level stuff and is required for a lot of cool rendering techniques.

I don't think jwz (who is much smarter than me) has many good things to say about OpenGL ES

http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

JWZ isn't saying that OpenGL ES isn't the good part of OpenGL, he's saying that nobody should ever have removed things from OpenGL in the first place, because he wants to port ancient code to modern systems.

Another way to take it is that ES removes too much from OpenGL.

In any case, I submit to the opinion of experts - my experiments with OpenGL have been simple and, when I attempted anything more complicated, they resulted in much more frustration than learning.

"because he wants to port xscreensaver code to iOS."

fixed that for you.

"jwz" and "Get off my lawn" are practically synonymous at this point. He's a great hacker, and a fantastic writer, but his priorities are entirely different from most developers.

Reply on news.ycombinator.com