Printable View
Phoronix: A Look At OpenGL ES 3.0: Lots Of Good Stuff
The OpenGL ES 3.0 specification was released earlier this week at SIGGRAPH 2012. The slides from the OpenGL ES BoF session have now surfaced with more perspective on this latest Khronos standard targeting OpenGL on mobile devices...
http://www.phoronix.com/vr.php?view=MTE1ODQ
Okay everyone, take a look at the shader code porting slide.
Now, hands up anyone who wanted to vomit after reading the "new and improved" glsl es 3.0 syntax.
What, you saw the line with "location" and that makes you vomit? Are you so feeble minded? It just shows that you can specify the location in the new version.Quote:
Originally Posted by curaga
There's other nice stuff, "varying" is gone, "in" is in, you can use your own (mnemonic) words instead of gl_FragColor, and other neat stuff.
Don't worry, you're not smarter than the devs from AMD, Nvidia, Intel etc who worked on the specs, so the specs are fine and carefully crafted.
+1Quote:
Originally Posted by mark45
Some people are so quick to reject anything different than what they're already used to, without giving the new ideas thorough, unbiased consideration. Granted every new idea isn't good, but you should at least give an alternative or explanation to your sensationalist statements. For the most part, GLES 3.0 looks like a great improvement all around, and with Intel bringing it to Mesa by early next year (i'm sure Mac will follow suit as well), I'm hoping it becomes the new "base line" architecture we need to build against for modern applications.
Yes, the syntax sucks. The actual _feature_ of the syntax is 1000x better than what was there before. Sometimes great advancements come wrapped in terrible packages. :)
If you want to know one of the reasons why I constantly complain about OpenGL/GLSL being so crappy and D3D/HLSL is so much better, now you know. HLSL has had the "new" way of linking shader stages for years (which among other things is a hard prerequisite for separable shaders), but without the horrible syntax Khronos saddled GLSL with. Why in $DEITY's name Khronos picked the awkward obtuse location thing instead of doing it like HLSL did -- which is clean, readable, and concise -- is beyond me.
Fine, prepare for an elanthis-like essay nobody bothers to read, because it's way too long.
The new linking model, while more flexible, requires much more boilerplate. This is a
clear step backwards. Before you didn't have to do the several calls binding names to numbers.
A much better model would be to default to the current ones, and if *and only if* the user
wishes to override, then override. This would let one use gl_FragData[3] and yet bind an
input to their desired name if they wish.
The syntax is just plain bad. I just woke up and yet I could do much better.
Case 1: "precision mediump float;"
Precision is entirely redundant, it's there in the "p". Nuke it. New syntax: "medp float;".
Case 2: "layout(location = 0) out vec4 data;"
Sweet jesus how horrifying. That thing is more verbose than Java. And Java's trying really
hard.
New try: "out vec4 data: 0;". I still don't like in and out, but can't think of a change
there right now. Even varying was better, but with the coming geometry shaders that wouldn't
be sensible any longer.
I say "the new syntax is bad". You want me to write an essay on the topic? Surely you canQuote:
Some people are so quick to reject anything different than what they're already used
to, without giving the new ideas thorough, unbiased consideration. Granted every new idea
isn't good, but you should at least give an alternative or explanation to your
sensationalist statements.
see yourself how it's bad.
Ad-hom, yeah. Nothing like personal insults to get a day started.Quote:
Don't worry, you're not smarter than the devs from AMD, Nvidia, Intel etc who worked
on the specs, so the specs are fine and carefully crafted.
It is Khronos who decides the syntax. The syntax happens to be absolutely horrible.
How is this related, at all, to the intelligence of a random dev at corp $foo or some forum
poster.
bye Directx!
well to be honest is a question of personal view some ppl prefer to work with condensed syntax and other prefer more expanded versions, i particulary prefer verbose coding since in the long run when things get very massive in lines makes your life easierQuote:
Originally Posted by curaga
for example:[c++]
i hate case:
my_type DecImg(my_vector x, my_vector y, bool cond) <-- many of the devs i work with like to make me suffer with this
i like case:
Ect2_img_data DecodeECT2ImageAVX(m_vector_256 BlockAfromSwizzle, m_vector_256 BlockBfromSwizzle, bool FrameEndedSignaliing)
sure case 1 is easy to write but when you need to debug a 200k lines program is insane while case 2 is a swift and i would love if c++ syntax could be even more verbose but as you see is a matter of tastes
The one thing I want most from some next-gen ES spec is a way to accelerate 2d elements such as bezier curves and elliptical arcs. It should be possible for the GPU to generate the interpolated points from the control points. Any ideas how to get that? If only they had included geometry shaders.
Another thing I want (and another way to accelerate curve rendering) is a way to send vertices across as 8-bit deltas rather than full 32-bit floats. Haven't figured out how to do that with ES 2.0 either.
Vert packing is an old trick, you can create any complex system you like as long as you can also unpack in a vertex shader.
You sure it will be a benefit though?