Announcement

Collapse
No announcement yet.

Rich Geldreich Leaves Valves; Points To More "End Of OpenGL" Articles

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

  • Rich Geldreich Leaves Valves; Points To More "End Of OpenGL" Articles

    Phoronix: Rich Geldreich Leaves Valves; Points To More "End Of OpenGL" Articles

    First of all, Rich Geldreich has left Valve. Geldreich was involved with Valve's OpenGL and Linux efforts and has spoken at Steam Dev Days, GDC, SIGGRAPH, and other conferences along with contributed to some open-source projects...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    very nice

    the guy removes the coments from this blog lol apple are paying a lot i see

    Comment


    • #3
      I don't doubt that OpenGL has problems, but that's going a little far. To the point where I have to wonder who paid Rich off. OpenGL 5 was already said to reduce overhead like DX12/Mantle/Metal. Like Mantle, Metal won't have much of a future if it can't exist on Windows, Linux, and Android. I doubt it will.

      Comment


      • #4
        OpenGL 5 was already said to reduce overhead like DX12/Mantle/Metal. Like Mantle, Metal won't have much of a future if it can't exist on Windows, Linux, and Android. I doubt it will.
        Well, one, there is no working draft of OGL5 yet, so we have no idea what it will be like. If they do it right, it could be a new profile of extremely low overhead functionality that can release concurrently with GLES4 to provide similar workflows for both. If they do it wrong, they could just add another few dozen functions rendered useless in 5 years besides the need to implement them for standards compatibility even if nobody uses them.

        Second, while I think concepts like Metal and Mantle are stupid, that doesn't mean they don't have validity - most platforms have single-platform toolkits already, and also effectively have single platform languages (objc, java on dalvik, c# on .net, hell Vala with GTK on Linux) so it stands to reason that having platform specific graphics APIs doesn't mean they instantly fail, since you are often writing platform specific code already.

        But it does mean your value proposition has to be really good to match up against cross platform write once debug lightly everywhere deploy with very little per platform modification solutions like Qt, Mono, or HTML5. In the same sense, any non-open graphics standard has to be significantly better for either the developer or user than OGL / ES to woo investment over.

        And yeah, it can happen. Like I said, it happens with toolkits all the time. But you would have a real hard time persuading me, if I were investing in a software project, to not use a cross platform toolkit because to be platform locked means to vastly reduce my potential audience size. Same with graphics API commitments.

        Comment


        • #5
          So he gives talks about OpenGL, then he bashes OpenGL, then he stops using it. It really sounds like something a child would do if they didn't get their way. Other APIs are good thing, everything evolves with more ideas and competition. OpenGL has a lot of legacy to support so a move to really modernize it would probably cause as much controversy as 3.x and trying to depreciate functionality.

          Comment


          • #6
            Sounds like someone just got a better job offer from Apple.

            Comment


            • #7
              I'm still really trying to understand WHY openGL is so much worse. It seems several developers lately complain about it but don't give specifics. They just give the most vague statements. I understand it might not be as polished as directX, but what I really don't get is if openGL is open source, couldn't you just simply modify it at the source to fix where it fails? That being said, why is something like OGL5 necessary when you could just theoretically re-write openGL to have less CPU overhead while retaining the exact same functionality? To put it another way, why re-invent the wheel when you can take the exact same model and just use a different material?

              I don't know enough about how OGL works on the lower level, and especially the hardware level. But there just seems to be too many "plot holes" for the claimed problems of OGL.

              Comment


              • #8
                heh... as I've mentioned before there is a tremendous amount of pressure in this industry to subvert SteamOS and Linux gaming and Android too. Nobody cared until Valve came out with guns blazing and posed a credible threat to the status quo. If people think that MS and Apple are just going to sit back and ignore what's going on, that's naive.

                I'm sure that Rich made his post either knowing he was on the way out or he got booted by Valve after making it.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  I'm still really trying to understand WHY openGL is so much worse. It seems several developers lately complain about it but don't give specifics. They just give the most vague statements. I understand it might not be as polished as directX, but what I really don't get is if openGL is open source, couldn't you just simply modify it at the source to fix where it fails? That being said, why is something like OGL5 necessary when you could just theoretically re-write openGL to have less CPU overhead while retaining the exact same functionality? To put it another way, why re-invent the wheel when you can take the exact same model and just use a different material?

                  I don't know enough about how OGL works on the lower level, and especially the hardware level. But there just seems to be too many "plot holes" for the claimed problems of OGL.
                  My thoughts exactly. The same people who were extolling the virtues of "zero overhead OGL" are now complaining that it's not "close enough to the metal". Which is, btw, nearly a complete marketing slogan at this point.

                  There are no serious technical reasons... there are only vendor lock-in reasons. MS isn't a stupid company. They made D3D for a reason. Same with Apple. Same with AMD.

                  I also don't understand the idea of wiping out "legacy API". You don't have to use it. That's like saying you can't use Swing because AWT is still in JFC. GLES is supposed to be "lean" and even that's not good enough according to these people.

                  I take it all with a grain of salt. There's A LOT of politics out there.

                  Comment


                  • #10
                    Originally posted by schmidtbag View Post
                    I'm still really trying to understand WHY openGL is so much worse.
                    Hi guys, been working on game development for a while (also author of this http://www.godotengine.org ), and while my experience on using bare metal GPU hardware is more from working with consoles than with drivers, here are my thoughts about it.

                    There are basically two different "problems" with OpenGL.

                    1) API Overhead

                    This is what stuff like Mantle or DX12 attempt to solve. It means that :

                    a) The CPU is doing too much work and limits the performance of video hardware.
                    b) The programmer has no control on driver optimizations.

                    I honestly think this is kind of stupid. GPUs had this problem since the beginning of times, and the way to solve it was adding extra APIs that move CPU processing to the GPU, which is why features such as direct rendering, buffer objects, shaders, instancing, OpenCL etc were created.
                    Making the API closer to the hardware is nice, but it's not going to solve anything on the long run as the gains are very limited in a very limited set of situations. Again moving what is slow from CPU to GPU solves problems, making the GPU save a little time doesn't.

                    2) Hardware Compatibility

                    It's easy to blame OpenGL here. The problem is mainly that the specs dictated by OpenGL are much more loose than those dictated than DirectX, and each vendor implements whathever they want. Microsoft played API police really well the past decade and ensured every device would comply, but at the same time there were only 2 implementers, Ati and NVidia and Intel couldn't even be taken seriously until recently.

                    How many OpenGL implementers are there? AMD, NVidia, Intel, Qualcomm, ARM, Imagination and a handful other asian vendors. It's definitely not as simple and not as easy, but it only takes testing your code on each one to make sure it works. For example, if your code runs on one Adreno device, it will most likely run in all others.

                    Comment

                    Working...
                    X