| |||||||||||||
Valve: Steam’d PenguinsValve: Steam’d PenguinsPosted Jul 18, 2012 19:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: Valve: Steam’d Penguins by Del- Parent article: Valve: Steam’d Penguins
> How is that relevant at all. Directx10 is not available on Windows XP.
And who cares? D3D10 is still better.
> "Because Direct3D 10 hardware was comparatively rare after the initial release of Windows Vista and because of the massive installed base of non-Direct3D 10 compatible graphics cards, the first Direct3D 10-compatible games still provide Direct3D 9 render paths.
However, if we're talking about D3D9 vs. OpenGL2 then D3D9 not only wins, but SLAUGHTERS OpenGL completely. Mostly because any real-life complex OpenGL codebase had to have special code paths FOR EACH HARDWARE VENDOR.
Even after OpenGL3.0 it wasn't uncommon to have special codepaths to handle a couple of not-yet-standardized vendor extensions.
>OpenGL started deprecating legacy stuff with 4.0. The criticism from 3.0 (long peaks ordeal) became rather silent with subsequent quick releases from Khronos.
>Today I see little reason to favour D3D.
OpenGL is STILL dependent on hidden thread-local rendering context. We STILL have to use object names (handles) instead of direct pointers. Object creation is STILL not atomic and objects are mutable.
Don't believe me? Then look at parallel code that attempts to create and manipulate OpenGL objects from different threads. Or just read stuff like this: http://hacksoflife.blogspot.com/2008/02/creating-opengl-o...
With D3D10/11 things are braindead simple: you have a pointer to a device object and you simply call its methods. And you can do this from multiple threads. Created objects are immutable (a 2D texture can't magically become 1D texture).
(Log in to post comments)
Valve: Steam’d Penguins Posted Jul 18, 2012 21:30 UTC (Wed) by daniel (subscriber, #3181) [Link] We STILL have to use object names (handles) instead of direct pointers. Object creation is STILL not atomic and objects are mutable.... With D3D10/11 things are braindead simple: you have a pointer to a device object and you simply call its methods. And you can do this from multiple threads. Created objects are immutable (a 2D texture can't magically become 1D texture).Arg, you have got to be kidding. Avoiding pointers as much as possible through the use of integer handles is a huge advantage for OpenGL in terms of, for example, avoiding segfaults and being able to debug easily, and at the same time maps better to the hardware, which can't use those DirectX addresses directly I hope you know. If you want pointers and methods, write your own. It's easy. And you get exactly what you need instead of whatever Microsoft decided you should have. The mutable object thing... that's a big meh for me. So... a texture handle goes through a table in the driver and can therefore refer to any kind of supported texture? Big deal. At least, it provides a nice friendly way to represent empty/free objects. On balance I would rather have this than not. It is certainly not a reason to get worked up, one way or the other. As you are no doubt aware, the OpenGL DSA extension is maturing, which will be a great help for multi-CPU rendering and also a modest boost to single thread rendering performance. This would have been the centerpiece of Longs Peak, but let's be honest, that would have been rash. "Measure twice, cut once" and let's not throw out any babies with our bathwater. Executive summary: I don't know what you're going on about, or why.
Valve: Steam’d Penguins Posted Jul 19, 2012 11:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Arg, you have got to be kidding. Avoiding pointers as much as possible through the use of integer handles is a huge advantage for OpenGL in terms of, for example, avoiding segfaults and being able to debug easily
LOL. Cause getting mysterious GL errors is SO much better.
Oh, have I mentioned that GL handles are only 32-bit?
>The mutable object thing... that's a big meh for me. So... a texture handle goes through a table in the driver and can therefore refer to any kind of supported texture? Big deal.
And you'll get a special effects Oscar if you try to modify an object while it is being used by a shader.
Valve: Steam’d Penguins Posted Jul 18, 2012 22:17 UTC (Wed) by Del- (guest, #72641) [Link]
>Even after OpenGL3.0 it wasn't uncommon to have special codepaths to handle a couple of not-yet-standardized vendor extensions.
It is entirely up to you whether you use those extensions. Feature parity with D3D10/11 was already with OpenGL 3.2, OpenGL3 is supported by any relevant driver on linux these days. What you seem to ignore is that the extensions is one of the mechanisms that allow OpenGL to advance, it is a way to thread water with new functionality. If it works out well and developers like it, it has a high probablity of being added in the next iteration of OpenGL. If it bothers you, then simply target a specific OpenGL version. That was even worse with D3D where targeting version was standardised only with D3D10 as far as I recall.
>It's just that everybody have resigned themselves to the inevitable. We're not getting Longs Peak so we might as well shut up and continue to deal with the legacy crap.
No they don't. The pointer issue has been openly discussed, you just need to go where the discussion is at. You seem to believe that you know what opengl5 should look like. Hence, I challenge you to share your views here:
|
|||||||||||||