Announcement

Collapse
No announcement yet.

Former AMD Developer: OpenGL Is Broken

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by blackout23 View Post
    EGL is just a way to create an OpenGL context on a windowing system much like what GLX is to OpenGL for the X windowing system.
    I think I understand.
    That means that in the end, if we have a device that use EGL, it still need OpenGL, right?

    Thanks.

    Comment


    • #17
      Originally posted by DebianLinuxero View Post
      I think I understand.
      That means that in the end, if we have a device that use EGL, it still need OpenGL, right?

      Thanks.
      They are orthogonal concepts. You use EGL to setup an OpenGL, OpenGL ES or OpenVG context, then use that context to render graphics with OpenGL, OpenGL ES or OpenVG.

      Comment


      • #18
        (Double post for some reason)
        Last edited by Ericg; 05-31-2014, 11:46 AM.

        Comment


        • #19
          Originally posted by DebianLinuxero View Post
          A very serious statement.

          I don't know much about the topic, (I think EGL is a subset of OpenGL) maybe someone could explain if that could apply to EGL too.
          When you target OpenGL you still have some differences between Windows, Linux, OS X, etc. Most devs would abstract away the differences in their own custom-solutions. EGL is a Khronos-official abstraction for all the OS differences.*

          *Greatly simplified, but you hopefully get the idea.

          https://www.opengl.org/discussion_bo...s-in-the-stack
          If EGL can be used on the desktop, is its window manager interface functionality intended to abstract the differences in GLX, WGL, and whatever the Mac OS equivalent is ? Or could it replace all 3 of those together?
          Yes, that is the intent. EGL started with the GLX API and then was genericized to replace X Windows-specific concepts with (hopefully) portable equivalents. EGL has also been evolving into a more significant role as the resource manager when using multiple Khronos APIs together, especially through the EGLImage family of extensions. OpenGL / ES, OpenVG, and OpenWF all can interact with or make use of EGL already, and there is work underway to extend that to more of our APIs.

          Comment


          • #20
            Originally posted by schmidtbag View Post
            Isn't openGL 5 supposed to fix some of his complaints, particularly the Mantle approach? While I don't code anything in 3D, I am curious as to what specifically openGL needs to do or is missing. I understand DX has always been easier to work with, but that doesn't mean its better. As Valve employees have shown, they got better performance out of openGL vs DirectX.
            well it was *supposed* to happen with openGL 3, but that didn't happen. Also I don't remember who off the top of my head but I know that there have been blogs where other people have gotten the opposite results with their game. Civilization comes to mind but i don't think that was it.

            Comment


            • #21
              There can certainly be a temptation to read one of these posts -- and with the author being a bit of an authority on the subject matter and all -- conclude that we have the final story and assume the worst. I would recommend tempering such thoughts.

              Certainly it would be preposterous to say that OpenGL is above criticism or already a perfect API or completely free of opportunities to reduce inefficiencies, but these ideas going around about how it is fundamentally broken and needs to be redone from scratch or whatever are just silly.

              Many of these criticisms aren't even that substantial (IMO) and seem to more reflect the immaturity of OGL experience in the contemporary game developer community than a fundamental API failure.

              Look on the bright side at least: OGL is faster than D3D. He could have least concluded his article with that fact. A broken API is faster than D3D. What does that say about D3D?

              Comment


              • #22
                In OpenGL there's no need for throwing all out of the window because it's been modified in every major version with big changes between versions, adapting to hardware.

                X protocol is an old protocol which has remained the same for years with some extensions to support new features but the core of the protocol is the same dated, rigid thing.

                For OpenGL 5 they could try to finally make a more streamlined API and add all the improvements suggested. Also a program for certification or a test conformance suite publicly available would help a lot. Driver makers could advertise that they are compliant with the tests.

                Comment


                • #23
                  Originally posted by DebianLinuxero View Post
                  I think I understand.
                  That means that in the end, if we have a device that use EGL, it still need OpenGL, right?

                  Thanks.
                  EGL is usually used together with OpenGL ES, which is the one that is mostly a subset of OpenGL.

                  Comment


                  • #24
                    There is a saying in my native language that roughly translates to "To a crooked rocket even space is impeding", I've also heard the same analogy expressed by a crooked male organ having problem with the female one...

                    Comment


                    • #25
                      So when something called OpenXXX needs to be reworked from scratch...does that mean we'll have LibreGL in a few weeks?

                      Comment


                      • #26
                        Some criticisms may be valid if you compare c.2009 GL vs. DX11. Not valid for 4.4.

                        Much criticism is based on dated knowledge. Too much "GL doesn't have X" where X was added recently.
                        The problem is not what OGL 4.4 is capable of, but that nobody supports it. OSX is stuck at 4.2, Linux is at 3.3, Windows usually doesn't work at all because everyone is using DirectX anyway. Mobile is in just as a bad a spot, except most GLES3 features on Android don't work at all because those drivers are concentrated shit.

                        People like DirectX because they can ship two versions of a game - DirectX9 for old hardware, DirectX11 for new. Or just ignore old stuff and ship 11 alone. For OpenGL, there is a sliding scale of hardware support from 2.1 to 4.4 (and I'm talking about parts from the last 5 years!), every version in between, plus vendor extensions.

                        I'm wondering if there would be a way to mix llvmpipe and legacy hardware to provide 3.3 compliance with software codepaths for unsupported extensions? There would of course be huge performance penalties when code touched software rendering paths, but it seems like a compromise to just say "target 3.3, use 4 branch extensions where you can, don't worry about the rest" or even GLES3 + extensions so you can have a portable mobile engine.

                        Comment


                        • #27
                          Originally posted by kaprikawn View Post
                          ... They want to maintain backwards compatibility. D3D is pretty much a gaming-focussed API, so MS has much more leeway to re-design from scratch, ...
                          I disagree. There is nothing in D3D that classifies it as a gaming API, and backwards compatibility is not a problem at all. I think you meant "forward compatibility", which shouldn't be a problem anyway for experienced developers (interface abstraction).
                          To be honest I always hear this kind of arguments coming from non-developers. If you're not a developer, please don't mention things you're not completely sure about.

                          Originally posted by johnc View Post
                          There can certainly be a temptation to read one of these posts -- and with the author being a bit of an authority on the subject matter and all -- conclude that we have the final story and assume the worst. I would recommend tempering such thoughts.

                          Certainly it would be preposterous to say that OpenGL is above criticism or already a perfect API or completely free of opportunities to reduce inefficiencies, but these ideas going around about how it is fundamentally broken and needs to be redone from scratch or whatever are just silly.

                          Many of these criticisms aren't even that substantial (IMO) and seem to more reflect the immaturity of OGL experience in the contemporary game developer community than a fundamental API failure.
                          Your train of thought seems guided by something else than just facts. There are very clear flaws present in GL - even in the most recent versions - that aren't present in D3D, and denying it is just silly.

                          Originally posted by johnc View Post
                          Look on the bright side at least: OGL is faster than D3D. He could have least concluded his article with that fact. A broken API is faster than D3D. What does that say about D3D?
                          Without further investigation it says nothing at all really... I have real doubts such performance advantage is noticable in real world applications though, unless you're referring to indirect draws which are very recent in GL and will have something comparable with D3D12 for sure.

                          Comment


                          • #28
                            Active Video Gamer: AMD is broken

                            I mean...it's obvious. OpenGL is working. The only things not working here are the proprietary drivers of AMD and NVidia.

                            Comment


                            • #29
                              Originally posted by Detructor View Post
                              Active Video Gamer: AMD is broken

                              I mean...it's obvious. OpenGL is working. The only things not working here are the proprietary drivers of AMD and NVidia.
                              nVidia blob drivers are OK, problem is with AMD ( bad drivers ) & Intel ( only OpenGL 3.3 on Linux )

                              Comment


                              • #30
                                Originally posted by sgtGarcia View Post
                                nVidia blob drivers are OK, problem is with AMD ( bad drivers ) & Intel ( only OpenGL 3.3 on Linux )
                                fact: nVidia blob drivers are more relaxed when following the standard + game developers are lazy to follow the GL standard, therefore many applications work fine on nVidia, but not on AMD, and then people complain that it's AMD's fault...

                                Comment

                                Working...
                                X