Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: A Look At OpenGL ES 3.0: Lots Of Good Stuff

  1. #1
    Join Date
    Jan 2007
    Posts
    14,348

    Default A Look At OpenGL ES 3.0: Lots Of Good Stuff

    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

  2. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    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.

  3. #3
    Join Date
    May 2012
    Posts
    762

    Default

    Quote Originally Posted by curaga View Post
    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.

    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.
    Last edited by mark45; 08-12-2012 at 07:01 PM.

  4. #4
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    303

    Default

    Quote Originally Posted by mark45 View Post
    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.

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

    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.

  5. #5
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    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.

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    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.


    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.
    I say "the new syntax is bad". You want me to write an essay on the topic? Surely you can
    see yourself how it's bad.

    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.
    Ad-hom, yeah. Nothing like personal insults to get a day started.

    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.

  7. #7
    Join Date
    Nov 2010
    Posts
    394

    Default

    bye Directx!

  8. #8
    Join Date
    Jun 2009
    Posts
    1,095

    Default

    Quote Originally Posted by curaga View Post
    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 can
    see yourself how it's bad.



    Ad-hom, yeah. Nothing like personal insults to get a day started.

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

    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

  9. #9
    Join Date
    Sep 2012
    Posts
    2

    Default why still no geometry shaders?

    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.

  10. #10
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •