Recent Features
| |||||||||||||
Valve: Steam’d PenguinsValve: Steam’d PenguinsPosted Jul 18, 2012 3:37 UTC (Wed) by slashdot (guest, #22014)In reply to: Valve: Steam’d Penguins by shmerl Parent article: Valve: Steam’d Penguins
The basic problem of OpenGL is that it is a hugely bloated interface, and as a whole doesn't fit well either modern hardware or modern games.
However, it generally supports all GPU features (and often more than DirectX thanks to extensions), so it's mostly a performance, correctness and ease of use problem.
The fact that almost all Windows games use DirectX when they could instead use OpenGL is pretty telling (and no, there are no roadblocks to using OpenGL on Windows).
(Log in to post comments)
Valve: Steam’d Penguins Posted Jul 18, 2012 4:09 UTC (Wed) by traverse (guest, #85812) [Link]
Except that Microsoft has been careful to ensure that there _are_ roadblocks to using OpenGL in Windows. Like any open or portable API, OpenGL makes it harder for Microsoft to achieve vendor lock-in, so their strategy towards it is all too predictable. Educate yourself: [http://www.grokdoc.net/index.php/Dirty_Tricks_history#Ope....
Valve: Steam’d Penguins Posted Jul 18, 2012 5:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
It's misleading and incorrect.
For example:
>The big problem is that MS isn't telling the video card manufacturers how to do that.
>Thus MS is telling ISVs to port all their OpenGL applications to Direct3D (of course) or risk losing customers because they can't have a "full rich 3D experience".
Valve: Steam’d Penguins Posted Jul 18, 2012 13:20 UTC (Wed) by Del- (guest, #72641) [Link]
Hm, less misleading than your post I would say. You cherry pick a couple of statements from the wiki which contains lengthy information and elaborations on the exact same points. It is a wiki you know, consider spending your efforts correcting the statements you believe to be erroneous or misleading instead of misleading readers here.
The Windows Vista beta clearly signalled that Microsoft smelled OpenGL blood, OpenGL was planned to be a second rate citizen. The outcry on the opengl forum probably reached you too. From my recollection Microsoft never came out with any re-assurance, developers had to test later releases to find out that windowed opengl apps could be used with aero desktop. I am not at all sure Mircosoft would have yielded had not Vista been such a flop. This was at the time when game developers started to show interest for OSX. If you put your own money on a new game engine for windows, would you dare put your money on opengl, or would you make sure you had d3d covered? Sometimes it is enough to scare people into submission you know.
Since the anti-trust case in 1998, Microsoft have become more subtle in the way hurdles are laid out. The lack of native support for OpenGL is one such subtle hurdle, yes you can circumvent it, but is is an annoyance and extra burden none the less. It means lack of fall-back should the customers video driver miss functionality. It means low or no integration with other tools or api's on the platform. Moreover, the xbox only supporting all those other windows native developer tools is a rather strong incentive to go with the Microsoft tools all the way on windows, on xbox you will need to do the effort anyway.
Now, do you have any information supporting that d3d is superior to opengl in any way? If not, why the heck do we have d3d at all.
Valve: Steam’d Penguins Posted Jul 18, 2012 13:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>Now, do you have any information supporting that d3d is superior to opengl in any way? If not, why the heck do we have d3d at all.
It's very well known in the industry. D3D10 is a very nice and clean API, it could be implemented with Gallium3D by one developer in a short amount of time. They've thrown away all the legacy fixed pipe crap and instead implemented everything with programmable shaders.
Other than that, tools for D3D development (shader debugger, IDE support, etc) are superb.
Valve: Steam’d Penguins Posted Jul 18, 2012 18:38 UTC (Wed) by Del- (guest, #72641) [Link]
>It's very well known in the industry. D3D10 is a very nice and clean API, it could be implemented with Gallium3D by one developer in a short amount of time.
How is that relevant at all. Directx10 is not available on Windows XP. This quote is quite telling:
"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. Examples of such titles are games originally written for Direct3D 9 and ported to Direct3D 10 after their release, such as Company of Heroes, or games originally developed for Direct3D 9 with a Direct3D 10 path retrofitted later in development, such as Hellgate: London or Crysis."
ref. http://en.wikipedia.org/wiki/Microsoft_Direct3D#Direct3D_10
>They've thrown away all the legacy fixed pipe crap and instead implemented everything with programmable shaders.
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.
Valve: Steam’d Penguins Posted Jul 18, 2012 19:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
> 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).
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:
Valve: Steam’d Penguins Posted Jul 18, 2012 22:11 UTC (Wed) by daniel (subscriber, #3181) [Link] Other than that, tools for D3D development (shader debugger, IDE support, etc) are superb.Perhaps you need some of this. In any case, I just started doing serious shader development. Development stack: Mesa + Xorg Radeon. Elapsed time to get a decent per-pixel Phong shader up and running: about four hours from start to finish, and that was only because I had next to no clue what I was doing at the time. (What's a uniform??) I especially like the way you can dump the IR (intermediate representation) for the code to the console just by setting an environment variable.
Valve: Steam’d Penguins Posted Jul 18, 2012 16:16 UTC (Wed) by drag (subscriber, #31333) [Link]
> Since the anti-trust case in 1998, Microsoft have become more subtle in the way hurdles are laid out.
Microsoft learned that they have to play the 'big corporate' game of pay offs and supporting popular initiatives even if it means supporting corrupt-to-the-core stuff. (which is the vast majority of things).
> The lack of native support for OpenGL is one such subtle hurdle, yes you can circumvent it, but is is an annoyance and extra burden none the less
Hardware/drivers provide their own OpenGL stack anyways. This is the way it's always worked for OpenGL. The whole 'Second rate OpenGL' thing is a bit of a red-herring. By the time Microsoft Vista came out OpenGL already fell out of favor.
ID was the only company actually seriously using OpenGL long before Vista. Other game engines supported OpenGL back-ends, but it wasn't for mainstream gaming.. it was more a of a specialty item. (like some Arcade machines ran Linux OpenGL)
The problem with OpenGL is that each vendor gave their own OpenGL stack. Which means that as a game designer you are not targeting 'OpenGL API' you are programming for: Intel's OpenGL API, Nvidia's OpenGL API, ATI's OpenGL, etc etc. Each vendor had subtle differences and different bugs to work around. Not to also mention that in order to be 'cutting' edge you had to deal with all the vendor-specific proprietary extensions.
With ActiveX you only had one vendor to deal with. This means that you didn't have proprietary extensions. It is consistent and worked just about the same regardless of what video card the user happened to have.
This is exactly the same thing that Linux needs. A consistent API, which hopefully we will get with decent open source drivers. It's the only way to get OpenGL working consistently on all Linux machines. Nvidia's stack is so much better then the OSS one that anything OSS supports so will Nvidia. That is the only proprietary OpenGL driver for Linux that is worth a damn.
Valve: Steam’d Penguins Posted Jul 18, 2012 21:45 UTC (Wed) by daniel (subscriber, #3181) [Link] The problem with OpenGL is that each vendor gave their own OpenGL stack. Which means that as a game designer you are not targeting 'OpenGL API' you are programming for: Intel's OpenGL API, Nvidia's OpenGL API, ATI's OpenGL, etc etc. Each vendor had subtle differences and different bugs to work around. Not to also mention that in order to be 'cutting' edge you had to deal with all the vendor-specific proprietary extensions.For year or two I develop exclusively on the open source Mesa + Radeon stack. Yes, it means I need to use a few extensions but big deal. It also means I run a little slower, but again big deal, the hardware is still stupidly fast. Both those issues pale next to the fact that I'm running a stack that I can count on, and that integrates well with the rest of my environment. I can say with complete confidence that this stack has become a joy to use. Here's a sample Notice the anisotropic filtering on the ground plane. Notice the ridiculously high triangle count. It's running at 60 FPS at high resolution on a $50 GPU. Big shoutout to everybody involved: Mesa guys, Radeon devs, Xorg, Freetype, GCC... It's not so much that these guys made this possible, as they made it pleasant. Now I'm just waiting for MSAA to land to perfect this stack. Not every far away. Last time I booted Catalyst was more than a year ago.
Valve: Steam’d Penguins Posted Jul 18, 2012 5:50 UTC (Wed) by slashdot (guest, #22014) [Link]
That's mostly false claims and speculation.
In the WDDM driver model introduced in Vista, the GPU vendor can implement OpenGL themselves, write GPU-specific command buffers, and then use the same GPU user<->kernel interfaces used for Direct3D to submit them.
And in fact ATI and nVidia offer the same OpenGL support on Windows that they offer on Linux.
Valve: Steam’d Penguins Posted Jul 18, 2012 21:55 UTC (Wed) by daniel (subscriber, #3181) [Link]
I suppose that Microsoft had no choice but to back off their efforts to undermine OpenGL support on Windows in part because they failed to convince some of the major CAD vendors to port to DirectX. After all, what is the point of supporting two different 3D backends when you don't have to? Much of high end CAD still runs on Unix workstations. There is no way the CAD vendors would have left those guys in the lurch.
Valve: Steam’d Penguins Posted Jul 18, 2012 16:08 UTC (Wed) by shmerl (guest, #65921) [Link]
OpenGL 4.x is not bad at all. The main roadblock is poor support by most vendors (except for Nvidia). Microsoft is guilty indirectly, since they pushed DirectX, which caused most manufacturers not to provide high quality drivers. Junky drivers don't allow even the best API to work as expected.
Valve: Steam’d Penguins Posted Jul 18, 2012 22:18 UTC (Wed) by daniel (subscriber, #3181) [Link]
"The main roadblock is poor support by most vendors (except for Nvidia"
AMD Catalyst is pretty darn good these days. (The only reason I don't use it is because Xorg Radeon is good enough.) Also, Intel's 3D stack has improved immensely. Not buggy and I'm even beginning to see something resembling frame rate out of it.
Valve: Steam’d Penguins Posted Jul 18, 2012 21:07 UTC (Wed) by daniel (subscriber, #3181) [Link] The basic problem of OpenGL is that it is a hugely bloated interface, and as a whole doesn't fit well either modern hardware or modern games. However, it generally supports all GPU features (and often more than DirectX thanks to extensions), so it's mostly a performance, correctness and ease of use problem. The fact that almost all Windows games use DirectX when they could instead use OpenGL is pretty telling (and no, there are no roadblocks to using OpenGL on Windows).You are out of touch with recent developments. For one thing, OpenGL currently dominates 3D gaming, with the exception of the XBox walled garden and the PC segment where Microsoft narrowly failed to kill it off. Otherwise, OpenGL is completely uncontested in the rapidly growing phone and tablet market, and is also PS3 and Nintendo. No game company in their right mind would start a new project that fails to support OpenGL. Modern OpenGL, 3.0+, has been cleanly factored into two parts: 1) a "legacy profile" that will eventually move to a separate library and 2) core OpenGL consisting of drawarrays, Vertex Buffer Objects, shader support, and various other facilities that map well to modern GPU hardware. There is no way you can describe OpenGL as bloated. It now ranks as one of the cleanest and most tightly defined libraries for anything, anywhere. And frankly, it is also very nice to have the friendly old legacy support around as an option, which in many cases is the quickest way to try out some new idea, then if it works out you put in the (modest) extra work to port it to the modern pipeline.
Valve: Steam’d Penguins Posted Jul 20, 2012 5:20 UTC (Fri) by elanthis (guest, #6227) [Link]
> You are out of touch with recent developments. For one thing, OpenGL currently dominates 3D gaming
Nowhere did he or anyone else claim that OpenGL wasn't widely used. What he claimed (and almost every other game developer around, including those who exclusively use OpenGL) is that OpenGL is a crappy API compared to D3D. Just like Linux nerds claim that Windows popularity has nothing to do with it having technical superiority, OpenGL's popularity has nothing to do with its having technical superiority.
> Otherwise, OpenGL is completely uncontested in the rapidly growing phone and tablet market,
So, OpenGL is the only option on those platforms, and "yay OpenGL!" D3D is the only option on XBox, and "damn you lock-in!"
> and is also PS3 and Nintendo.
Complete lie. Nintendo does NOT use OpenGL in any capacity. Not a single Nintendo console is even _capable_ of running OpenGL 2.x+, as Nintendo has never released a console with shader support (the upcoming WiiU will be their first), and the specialized hardware in the GC/Wii and the 3DS are not based on OpenGL's fixed function pipeline. PS3 does have a stripped down incomplete GL ES library, but no serious game uses it. Every real PS3 game uses a proprietary hardware-specific Sony API.
People use PS3 as a point in OpenGL's favor all the time because they read on Wikipedia that "PSGL" is a thing. Not one of these people are actual PS3 game developers. For the love of God, stop making claims on things you don't actually use in real life.
|
|||||||||||||
