Forums | MacLife

I've mainly been dealing with D3D and the PS3's graphics APIs lately, and since starting in the real world, I've been able to get a feel of what the cutting edge graphics requires. I've come to realize that OpenGL is definitely higher level than other graphics APIs, where they handle more resources for you. While nice for getting something running quickly, it doesn't allow you as much control over resources when you want to get the most out of the hardware, and it also adds a lot more complexity in drivers leading to more bugs.

Also, OpenGL has become very stagnant of late. When I read that they were just adding support for half floats in vertex buffers, I was surprised that they didn't implement it earlier. It appears that an extension was added a bit earlier, but it isn't supported on the Mac yet. D3D has had a large set of different vertex data formats in D3D 9, and probably earlier (though not always supported on all the cards), so it's pretty much old news for other APIs. (for those of you who don't know what I'm talking about, in short it saves memory and bandwidth)

I think they would do well to split OpenGL into 2 APIs: one that's higher level for programs that need to be robust, but don't need to use every last bit of the hardware, and one that allows for lower level control for performance hungry applications such as games. OpenGL already pretty much services the first need, since it was mainly built for scientific applications. However, I think having a mid-level API like D3D could certainly help, where it still does some resource handling for you (otherwise it wouldn't be able to support multiple vendor's cards), but allows for much more control over those resources.

Noooo, my posts are gone!!

I wrote something about ARB's long-standing tradition of emphasizing backwards compatibility over new features.  I also wrote that OpenGL is not "slower" than D3D, and performance is a direct consequence of implementation.  For example, in Windows, NVIDIA's implementation is typically faster than D3D.  Finally, I wrote that John Carmack is using D3D (in some capacity) in its Tech 5 engine.  It may be for something as simple as determining hardware features (a trivial task in D3D), to a an engine that fully supports both renderers.

Mr. T wrote:

Noooo, my posts are gone!!

I wrote something about ARB's long-standing tradition of emphasizing backwards compatibility over new features.  I also wrote that OpenGL is not "slower" than D3D, and performance is a direct consequence of implementation.  For example, in Windows, NVIDIA's implementation is typically faster than D3D.  Finally, I wrote that John Carmack is using D3D (in some capacity) in its Tech 5 engine.  It may be for something as simple as determining hardware features (a trivial task in D3D), to a an engine that fully supports both renderers.

I lost my last post as well. OpenGL may not be inherently slower, but with less control over the resources you aren't able to use as many tricks to try to improve performance and memory usage. Also, with the added driver complexity, you are more likely to run into driver bugs. That combined with OpenGL taking a back seat to D3D gives you a bad combination...

NightCougar_37 wrote:

Heck i'm happy here, i've always hated OpenGL ever since the OS9 days when Apple was going nuts about it. This is what Apple gets for dumping Glide/Rave .

As I said in my mysteriously missing post, a lower level library like glide can improve performance in the hands of a skilled developer, since it provides finer control over the resources. However, the two main things that destroy any possibility of this happening on PCs are the fact that multiple processes might need to access the video card at once and the differing hardware between cards and manufactures. All the consoles have a lot more control over the graphics hardware than the PC due to the fact that you're guaranteed to have one type of hardware and you only have to worry about your game running, but the PC doesn't even come close in those two requirements.

akb825 wrote:

Mr. T wrote:

Noooo, my posts are gone!!

I wrote something about ARB's long-standing tradition of emphasizing backwards compatibility over new features.  I also wrote that OpenGL is not "slower" than D3D, and performance is a direct consequence of implementation.  For example, in Windows, NVIDIA's implementation is typically faster than D3D.  Finally, I wrote that John Carmack is using D3D (in some capacity) in its Tech 5 engine.  It may be for something as simple as determining hardware features (a trivial task in D3D), to a an engine that fully supports both renderers.

I lost my last post as well. OpenGL may not be inherently slower, but with less control over the resources you aren't able to use as many tricks to try to improve performance and memory usage. Also, with the added driver complexity, you are more likely to run into driver bugs. That combined with OpenGL taking a back seat to D3D gives you a bad combination...

I'll take your word for it.  As I said before (erased), I don't have any experience with D3D.  Even in OpenGL, I'm still working on fixed-pipeline stuff, so I (technically, "we") can make something reasonably entertaining before going insane (most immediate goal being a third-person camera)...  And then on to bigger and better things.  I can see your point about the driver bugs, tho.

Last edited by Mr. T (2008-08-15 11:15 pm)

I think you have that in reverse: most companies use DirectX, not OpenGL.

Driver 177.89 - Open GL 3.0 - Siggraph 2008

The Windows 177.89 Drivers available via the links below, released during Siggraph 2008, enable the latest features including OpenGL 3.0 support.

This special page allows direct access to the new drivers for Siggraph attendees -- the drivers will become part of the standard release NVIDIA Graphics drivers in the days immediately following.

To enable/disable OpenGL 3.0 features, please use the latest nvemulate tool.

OpenGL 3.0 beta driver release notes
This driver is aimed at developers to start coding to the new OpenGL 3.0 and GLSL 1.30 features. These features are not enabled by default. They can be enabled using the nvemulate utility, as described here: http://developer.nvidia.com/object/nvemulate.html

You need one of the following graphics cards to enable the OpenGL 3.0 and GLSL 1.30 functionality.

Desktop: GeForce 8000 series or higher; GeForce GTX 260, 280; Quadro FX 370, 570, 1700, 3700, 4600, 4700x2, 5600
Notebook: GeForce 8000 series or higher; Quadro FX 360M, 370M, 570M, 770M, 1600M, 1700M, 2700M, 3600M, 3700M

This driver implements all of GLSL 1.30 and all of OpenGL 3.0, except for the following functionality:

One-channel (RED) and two-channel (RG) textures
Mixed size FBO attachments (mixed-format attachments are supported)
The Clearbuffer API
Windowless rendering support (We suggest you use GPU affinity instead)
Forward-compatible context
Debug Context
This driver exposes the following new extensions:

OpenGL 2.1 extensions:
ARB_vertex_array_object
ARB_framebuffer_object
ARB_half_float_vertex

OpenGL 3.0 extensions:
WGL_create_context
ARB_draw_instanced
ARB_geometry_shader4
ARB_texture_buffer_object
WGL_create_context

Etc.

http://developer.nvidia.com/object/opengl_3_driver.html

A member at iDevGames (thread here, for those that can follow it) was trying to implement a shadow mapping technique with OpenGL. So far, he's encountered a few driver bugs that have hampered his progress. Of course, there's other things such as the FBO bug that made Knights of the Old Republic run like crap in Dantooine, and the special enhancements that were released solely for Doom III. The list goes on at the problems with OpenGL drivers due to the combination of complexity and lack of attention...

macmenace wrote:

akb825 wrote:

I think you have that in reverse: most companies use DirectX, not OpenGL.

Most PC/Xbox developers do. But, Nintendo/Sony/Apple developers use OpenGL unless that have an in house graphics lib.

Akb825 informed us awhile back that the Wii uses a rather modified, proprietary OpenGL-based lib a bit like GLide (I'm sure I'll be somewhat corrected here), while of course it's most PC, all XBox (original & 360, albeit the 'Boxes have each had/have a custom version tailored to their hardware).* I think the PS3 is pretty straight OGL, but again akb25 can inform us directly. And it's a long time since any major games were devved for Mac, so it's more like porting issues than dev work, excepting a few lower-budget titles.


*Hence the backwards-compat issues

Let's make it easier...

Chen, H. and Liu, X. 2008. (Bungie). Lighting and Material in Halo 3. ACM SIGGRAPH 2008: Proceedings of the conference course notes, Advances in Real-Time Rendering in 3D Graphics and Games, Chapter 1, pp. 1-22, Los Angeles, CA, August 2008. PDF

4.16MB.

IIRC Halo and perhaps H2 had some nearly straight to the metal, nearly machine code-level optimizing to try to wring the most from a launch title in limited time and another that tried pushing the original Box's limits respectively. The Wii lib sounds a bit like GLide, and the 360 & PS3 libs like APIs halfway to the present CUDA and CTM/Brooke+, to be united in the coming year under the OpenCL label (tho that goes beyond graphics into stream computing and other more general apps). Should be an interesting year.

Above should be a good read. H3 has some nifty effects...


...Sci.

I'm sure you're right about those specifics; I was trying to, in some way, get at the lower-level nature of these new coding methods (ATi's was originally called CTM, Close To Metal, before it morphed into Brooke+ while I wasn't looking and extended beyond graphics. It's been around awhile, since before stream computing took off IIRC).

What I've heard of the PS3 jibes with your characterization, more or less. You can do things like particle systems on the SPUs, but's it's not trivial. Cell really excels at streaming media, but the ability to decode multiple HD streams at once isn't terribly utile in games. It's more for, sheer coincidence, home entertainment like BD playback. By contrast Halo 3's particle system is done on the GPU. IIRC physics aren't too easy for the SPUs, more the province of the central GP unit. Don't really remember about AI.

And yeah, stream out, one of the borrowed DX10 functions as I recall, is great.

Even if you can't put a whole subsystem (such as physics or AI) on the SPUs, you can at least put part of it on there to increase your speed. Believe me: there are plenty of places in games where you can utilize them.

What do you mean about tessellation in OGL 3.0? Tessellation is something that's API independent and is generally done on the software side, with the exception being geometry shaders. (which IIRC are supported in OpenGL 3.0)

Last edited by akb825 (2008-08-17 1:25 pm)