Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 69

Thread: Toward Version 4.3

  1. #31
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The only reason I could see why the ARB might consider making a third try for a new API (and again: they've tried it twice before) is because graphics cards aren't getting that many truly new features that require API extension.

    DX11.1 hardware features are... scant:

    • Shader tracing and compiler enhancements: Not a hardware feature. Not really.
    • Direct3D device sharing: Not a hardware feature.
    • Check support of new Direct3D 11.1 features and formats: Not a hardware feature.
    • Create larger constant buffers than a shader can access: Welcome to the party, D3D; glad you could make it
    • Use logical operations in a render target: Ditto.
    • Force the sample count to create a rasterizer state: Ditto.
    • Process video resources with shaders: Not a hardware feature, per-se.
    • Extended support for shared Texture2D resources: Not a hardware feature.
    • Change subresources with new copy options: Not a hardware feature.
    • Discard resources and resource views: Not a hardware feature.
    • Support a larger number of UAVs: Hardware feature yes, but only because D3D doesn't provide a query and a flexible count of these...
    • Bind a subrange of a constant buffer to a shader: Welcome to the party, D3D; glad you could make it
    • Retrieve the subrange of a constant buffer that is bound to a shader: Ditto.
    • Clear all or part of a resource view: It took you that long?
    • Map SRVs of dynamic buffers with NO_OVERWRITE: Welcome to the party, D3D; glad you could make it
    • Use UAVs at every pipeline stage: Welcome to the party, D3D; glad you could make it


    Most of these have little to do with actual hardware. Basically, since D3D11, standardized cross-vendor hardware features have been fairly few and far between. Sure, we've got AMD pushing virtual texturing. NVIDIA's pushing "bindless" textures. Other than that? No.

    One of the cited reasons to abandon Longs Peak was that it was taking too long, that OpenGL wasn't being responsive to new hardware. There isn't any right now. Or at least, not much that's cross-vendor.

    Again, I remind you: Do not get your hopes up! This will not happen, no matter how much you want it. The sooner you accept this, the better.

  2. #32
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264
    Quote Originally Posted by thokra View Post
    You don't even need to read past the first page to get stunned by massive amounts of irony. Of course, it's always better and easier to write and maintain more than 40 workarounds for crap that most likely has been redeemed by later GL revisions...

    I really, really hope that the team at Autodesk developing the product is the only one with that policy. Otherwise I'd have to find a new desk to compensate for the hole I smashed into it with my head.
    What do you mean by GL revisions? AFAIK, newer versions don't change much of the basics that these CAD programs are using (line rendering and non textured polygons).

    The stupidity I see is that they say OpenGL doesn't support Cubemap and that was posted during 2007 while GL 2.1 was around.
    The other big stupid thing is that they are using the software renderer (probably for preview and printing purposes) instead of using FBO. Again, we are talking about the GL 2.1 era when FBO support was available on ATI and nVidia. The FBO extension had been around since 2004 (GL 2.0).

    They are stuck in the stoneage of GL 1.1 obviously but I'm sure that they have discovered quite a few bugs which pisses them off.
    Someone should teach them how to use GLEW at least so that they can move to GL 2.1.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  3. #33
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129
    Quote Originally Posted by V-man
    What do you mean by GL revisions? AFAIK, newer versions don't change much of the basics that these CAD programs are using (line rendering and non textured polygons).
    What I wanted to say is that they would have easily profited by incrementally leveraging newer features and spec revisions which are usually acompanied by improved drivers which expose new features and, at least for the most mainstream features, reach pretty good stability at least on Windows after a few weeks or months. That's what I meant by redeemed. So I fully agree that their problems would probably just have gone away by turning their brains on and moving to 2.1. Furthermore, if a company like Autodesk can't convince AMD and NVIDIA to get their stuff working then I don't know who could.

    This whole development strategy blows my mind. Another thing I find very disturbing is the accuracy argument. If GL implementations from 1997 worked for them, how could they state 10 years later that the GL accuracy wasn't enough for their needs anymore? Didn't I read that part correctly?

  4. #34
    Junior Member Regular Contributor
    Join Date
    May 2012
    Posts
    100
    This is called the Direct3Dization of the graphics software industry. Prety much like the DOTNetization of software.

  5. #35
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Quote Originally Posted by V-man View Post
    They are stuck in the stoneage of GL 1.1 obviously but I'm sure that they have discovered quite a few bugs which pisses them off.
    Someone should teach them how to use GLEW at least so that they can move to GL 2.1.
    You are being pretty harsh here. Its not like CAD's are standing in the same place entire time. Yeah, they have loads of legacy code (ive seen some pretty crazy stuff in various cads) and switching overnight (or at all) is silly when they have something working (probably with shitload of workarounds and whatnot).

    Most arguments against clean API break are bullshit though. There is only one thats valid imo.
    If driver vendors were to commit to GL5.0 that has nothing to do with old GL, fixing old bugs will probably be lower priority (those same teams wont suddenly develop two drivers instead of one).

  6. #36
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264
    Quote Originally Posted by kyle_ View Post
    You are being pretty harsh here. Its not like CAD's are standing in the same place entire time. Yeah, they have loads of legacy code (ive seen some pretty crazy stuff in various cads) and switching overnight (or at all) is silly when they have something working (probably with shitload of workarounds and whatnot).
    We are now 2012, therefore 15 years have passed. During that time, they (Autodesk) never considered rewriting their renderer?
    But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.

    To me, it doesn't make much sense.
    Direct3D 10 isn't going to last forever. At some, point Microsoft will stop releasing updates and just move on. It happens to all their products.

    Furthermore, if a company like Autodesk can't convince AMD and NVIDIA to get their stuff working then I don't know who could.
    I don't understand it either.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  7. #37
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.
    To be quite honest, it probably will be.

    They won't have to deal with GL driver bugs. If they're going to start using advanced, shader-based features, then they will likely run into GL driver bugs quite quickly (just as many people on this site do). D3D implementations don't have nearly as many bugs. D3D even works on Intel hardware, where trusting in any OpenGL version beyond about 1.4 is foolish.

    They don't need cross-platform support.

    In short: given the stability differences, and given the fact that they need to rewrite their rendering system... which would you choose? Why would you choose OpenGL for a Windows-only program that you are basing your company's survival on?

    Can you think of even one reason to do so?

    Direct3D 10 isn't going to last forever. At some, point Microsoft will stop releasing updates and just move on.
    They will likely have planned for that. With a new codebase, rewritten from scratch (or near-enough), it'll likely be easier to switch API functions as they change. Besides, it's not like D3D10 is so massively different from D3D11 in terms of the basic API.

  8. #38
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129
    Quote Originally Posted by Alfonse Reinheart
    They don't need cross-platform support. [..] Why would you choose OpenGL for a Windows-only program that you are basing your company's survival on? Can you think of even one reason to do so?
    Nope, not me at least. However, an interesting question would be how many major companies out there think the same way and have already or will abandon their GL rendering code in the foreseeable future. If the amount was significant that would mean one major reason gone for not revamping the GL. (Which I too believe won't happen but I still maintain a glimpse of hope. ) Another question would be, why aren't any of the CAD guys running around the forum anyway? Have there been encounters in the past?

  9. #39
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    If i was a major company i probably wouldnt care for OpenGL at all (and i do like it, kind of). That is of course assuming i (as a company) dont care for mobile & mac or linux, which may not be true.

    Another question would be, why aren't any of the CAD guys running around the forum anyway? Have there been encounters in the past?
    How do you know that

  10. #40
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,129
    Quote Originally Posted by kyle_
    How do you know that
    Damn...

Posting Permissions

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