A technical blog from Daniel Rákos (aka aqnuep)
OpenGL vs DirectX: The War Is Far From Over
The War Is Far From Over
I’ve chosen the title based on the popular article that tries to prove that OpenGL lost the war against Direct3D. To be honest, I didn’t really like the article at all. First, because it compared OpenGL 3 which targeted Shader Model 4.0 hardware and DirectX 11 which targeted Shader Model 5.0 hardware. Besides that, as we will see, the war is really far from over… This article aims to list the most important features introduced by OpenGL 3.x, OpenGL 4.x, Direct3D 10, Direct3D 11 and we will also talk about the promised features of the upcoming Direct3D 11.1 to be fair with DirectX 
After I wrote my article about the latest features introduced in OpenGL someone asked me whether I can write an article about the comparison of the hardware features exposed by OpenGL and Direct3D. Instead of a long explanation, I decided to simply create a table of the features introduced by the APIs. Please note that the list focuses on hardware features and does not discuss API feature differences between the two APIs. The list may be far from complete and I’m happy to get feedback about what is missing from the table so that I can extend it. Also there are features for which I did not find whether an equivalent exists in D3D and are marked with a question mark. If anybody can point me to the answer, I would be happy, but I did not find a specification of the HLSL versions.
| HARDWARE FEATURES EXPOSED | |||||
| Draw command related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Conditional/predicated rendering based on the result of occlusion queries (NV_conditional_render) | |||||
| Basic geometry instancing support and instanced draw commands (ARB_draw_instanced) | |||||
| Geometry instancing with the ability to specify instanced vertex attributes (ARB_instanced_arrays) | |||||
| Primitive restart (cut index) feature for batching multiple strips together (NV_primitive_restart) | |||||
| Draw commands allowing modification of the base vertex index (ARB_draw_elements_base_vertex) | |||||
| Indirect draw commands that source their parameters from server side buffers (ARB_draw_indirect) | |||||
| New shader type related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Geometry shader support and adjacency primitive support (ARB_geometry_shader4) | |||||
| Instanced geometry shader support with fixed number of invocations (ARB_gpu_shader5) | |||||
| Tessellation control and evaluation (hull and domain) shader support (ARB_tessellation_shader) | |||||
| Transform feedback (stream-output) related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Basic transform feedback (stream-output) support (EXT_transform_feedback) | |||||
| Transform feedback support without a geometry shader being active (EXT_transform_feedback) | |||||
| Support for pausing and resuming transform feedback (stream-output) (ARB_transform_feedback2) | |||||
| Auto-draw support (feed back the contents of the transform feedback buffer) (ARB_transform_feedback2) | |||||
| Instanced auto-draw support (transform feedback buffer drawing with instancing support) (ARB_transform_feedback_instanced) | |||||
| Support for outputting multiple primitive streams using transform feedback (stream-output) (ARB_transform_feedback3) | |||||
| Asynchronous queries and related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Support for occlusion query for getting number of samples passed (ARB_occlusion_query) | |||||
| Support for occlusion query for getting only a boolean value about visibility (ARB_occlusion_query2) | |||||
| Support to query the number vertices processed and the number of vertex shader invocations | [1] | ||||
| Support to query the number of geometry shader invocations in case a geometry shader is active | [1] | ||||
| Support to query the number of primitives output by the geometry shader (EXT_transform_feedback) | |||||
| Support to query the number of primitives that were sent to the rasterizer (EXT_transform_feedback) | |||||
| Support to query the number of primitives that were passing clipping and were actually rendered | [1] | ||||
| Support to query the number of times a fragment/pixel shader was invoked | [1] | ||||
| Support to query the number of primitives written during transform feedback (stream-output) (EXT_transform_feedback) | |||||
| Support to query the number of primitives generated during transform feedback (stream-output) (EXT_transform_feedback) | |||||
| Support to query a server side high resolution timestamp (ARB_timer_query) | |||||
| Support to query the completeness of rendering commands (ARB_sync) | |||||
| Texture, vertex and renderbuffer format related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Floating point color and depth formats for textures and render buffers (various extensions) | |||||
| Cube map textures with depth component internal format (EXT_gpu_shader4) | |||||
| Half-float (16-bit) vertex and pixel data support (NV_half_float, ARB_half_float_pixel) | |||||
| Non-normalized integer color formats for textures and renderbuffers (EXT_texture_integer) | |||||
| Packed depth/stencil texture and renderbuffer formats (EXT_packed_depth_stencil) | |||||
| RGTC texture compression for two-component textures (EXT_texture_compression_rgtc) | |||||
| Signed normalized texture component formats (EXT_texture_snorm) | |||||
| Seamless cube map filtering support (to hide artifacts at cube map edges) (ARB_seamless_cube_map) | |||||
| Support for swizzling the components of a texture (ARB_texture_swizzle) | |||||
| BPTC texture compression for floating point and unsigned normalized textures (ARB_texture_compression_bptc) | |||||
| 64-bit floating point vertex attribute formats (ARB_vertex_attrib_64bit) | |||||
| New texture type related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| One- and two-dimensional layered array textures (EXT_texture_array) | |||||
| Cube map array textures as special two-dimensional array textures (ARB_texture_cube_map_array)) | |||||
| Rectangular textures with no mipmap support and that are accessed with integer coordinates (ARB_texture_rectangle) | |||||
| Multisampled textures and support for fetching specific sample locations (ARB_texture_multisample) | |||||
| Casting a texture’s interpreted internal format to another internal format | [4] | [4] | |||
| Uniform buffer (constant buffer) related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Basic uniform buffer (constant buffer) support (ARB_uniform_buffer_object) | |||||
| Support for large uniform buffers and binding subranges (ARB_uniform_buffer_object) | |||||
| Framebuffer and texture rendering related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Rendering to textures and renderbuffers (EXT_framebuffer_object) | |||||
| Multisample stretch blit functionality (EXT_framebuffer_multisample, EXT_framebuffer_blit) | |||||
| sRGB rendering and blending support for framebuffers (EXT_framebuffer_sRGB) | |||||
| Support for enabling or disabling clamping of the depth of fragments (ARB_depth_clamp) | |||||
| Support for logical operations on integer render targets (supported for a decade in OpenGL) | |||||
| Blending related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Support for alpha-to-coverage when using multisampling (ARB_multisample) | |||||
| Per-color-buffer blend enables and color writemasks (EXT_draw_buffers2) | |||||
| Dual-source color blending support based on a secondary output of the fragment shader (ARB_blend_func_extended) | |||||
| Individual blend equations and blend functions support for each color output (ARB_draw_buffers_blend) | |||||
| Shader related features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Texture lookup functions to access individual texels of a LOD using integer coordinates (EXT_gpu_shader4) | |||||
| Query the dimensions of a specific LOD of a texture in shaders (EXT_gpu_shader4) | |||||
| Ability to apply integer offsets to the texel location during texture lookup (EXT_gpu_shader4) | |||||
| Ability to explicitly pass in derivative values that are used to compute LOD during texture lookup (EXT_gpu_shader4) | |||||
| Control over varying variable interpolation: non-perspective, flat, centroid sampling, etc. (EXT_gpu_shader4) | |||||
| Full signed and unsigned integer support in shaders (EXT_gpu_shader4) | |||||
| Vertex ID built-in variable available in vertex shader (EXT_gpu_shader4) | |||||
| Primitive ID built-in variable available in geometry and fragment shader (EXT_gpu_shader4) | |||||
| Instance ID built-in variable available in vertex shader (ARB_draw_instanced) | |||||
| Shader fragment coordinate convention control (ARB_fragment_coord_conventions) | |||||
| Provoking vertex control (for flat shaded varying value selection) (ARB_provoking_vertex) | |||||
| Support for encoding and decoding floating point values from and to integers (ARB_shader_bit_encoding) | |||||
| Support for get the results of the automatic LOD computations in shaders (ARB_texture_query_lod) | |||||
| Support for coherent indexing into arrays of samplers using non-constant indices (addressable samplers) (ARB_gpu_shader5) | |||||
| Support for indexing into arrays of uniform blocks (addressable constant buffers) (ARB_gpu_shader5) | |||||
| Gathered texture fetches over a 2×2 footprint (with custom offsets) (ARB_texture_gather) | |||||
| Invocation ID built-in variable available in geometry shader (ARB_gpu_shader5) | |||||
| Support for double-precision floating-point data types in shaders (ARB_gpu_shader_fp64) | |||||
| Support for sample-frequency fragment shader execution (ARB_sample_shading) | |||||
| Support indirect subroutine calls in all shader stages (ARB_shader_subroutine) | |||||
| Support for selecting from multiple viewports using a geometry shader (ARB_viewport_array) | |||||
| Support for dedicated atomic counters in shaders (ARB_shader_atomic_counters) | [2] | [2] | |||
| Support for backing up dedicated atomic counters with buffers (ARB_shader_atomic_counters) | [5] | [5] | |||
| Support for load/store (read/write) buffers and textures in shaders (ARB_shader_image_load_store) | [3] | ||||
| Support for atomic operations on load/store buffers and textures (ARB_shader_image_load_store) | |||||
| Support for disabling or forcing early depth test (ARB_shader_image_load_store) | |||||
| Support for conservative depth (enabling safe early tests even when modifying depth) (ARB_conservative_depth) | |||||
| Support for coverage as input to the fragment shader (ARB_gpu_shader5) | |||||
| Miscellaneous features | |||||
| GL 3.x | GL 4.x | DX 10 | DX 11 | DX 11.1 | |
| Support for floating point viewport specification (ARB_viewport_array) | |||||
| Per-texture mipmap clamping (supported since the very early versions of OpenGL) | |||||
| Support to use a single depth texture for depth testing and as texture input (when depth writes are disabled) | |||||
[1] There is no support for these counters in OpenGL, however they can be implemented with the help of shader atomic counters.
[2] There is no support in Direct3D to use the dedicated atomic counter hardware (supported currently only by AMD GPUs) only by using an append/consume buffer. Though, as atomic counters are the part of UAVs and arbitrary number of UAVs can be attached to a single resource, the same functionality is supported indirectly.
[3] There is read/write buffer and texture support in Direct3D 11, however it is available only in the fragment (pixel) shader. Direct3D 11.1 plans to remove this restriction.
[4] There is no support for texture format casting in OpenGL, conversion, however, can be done by doing a copy preferably using pixel buffer objects.
[5] There is no support for automatic storage of atomic counter values in buffers in Direct3D, however, their value can be manually copied to arbitrary resources.
As a conclusion, I would like to say just one thing: even though there are some features that are not supported by either OpenGL or Direct3D, we really can say that the two APIs are on par with the number of hardware features they expose.
(Sorry in advance for any mistakes, it took quite some time to create this table and I may became too tired at the end)
| Print article | This entry was posted by Daniel Rákos on October 7, 2011 at 7:02 pm, and is filed under Graphics, Programming. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 7 months ago
“Transform feedback support without a geometry shader being active” – I’m pretty sure that’s supported on DX1x, you have to create a dummy geometry shader using CreateGeometryShaderWithStreamOutput but passing VS input signature bytecode (see documentation for this function).
In D3D9 days OGL vs D3D was about the infrastructure, not about the actual features – driver quality, frame/shader debuggers and profilers. Not sure how things are now – you can definitely ship an OGL game (then again you could do it back then), it’s just that relatively few people do.
about 7 months ago
Please modify the title of your article, you’re not comparing OpenGL against DirectX, but Direct3D
about 7 months ago
This is from an OpenGL point of view, but considering that 1) direct3d11 is a 2 years old API, 2) that was fully integrated with compute shaders, 3) supporting multithreading (ok, not working as expected on AMD graphics card) 4) supporting for downlevel hardware up to D3d9 (is it possible do that on a 5 years old graphics card using opengl 4.2?) and providing a consistent API without using any extensions, everything available from the Core API… D3D11 is still the best all-in-one API so far
about 7 months ago
Yawn, features how interesting… From this way of reasoning and my crystal ball experience I can tell how many games you shipped: zero.
The war is over because:
1) no one cares to fight it, no gamedev will loose his sleep over a gpu api
2) if anyone ever cared, then yes, on Pc dx clearly won. How do I know? Count the number of ogl games shipped in the last five years or so…
about 7 months ago
I am quite sure that Direct3D will lose in the long run as the world evolves away from proprietary Microsoft platforms. While OpenGL may not take over for it, it sure seems to be the most likely candidate.
If you’re Direct3D-only you can only deploy on a limited number of platforms: XBox (one of three major gaming consoles), Windows PCs (the biggest but not only PC platform) and Windows Phone (one of the smaller mobile platforms), while OpenGL is supported by ALL or almost all current platforms that have any kind of graphics capability. And with WebGL it will even become a standard for the biggest platform ever, the Web (excluding Microsoft’s browsers).
With the increasing importance of iOS and Android I see Direct3D on the way out, unless maybe Microsoft decides to open it up.
about 7 months ago
Wow! I didn’t expect that many comments so quickly, especially because yesterday a discussion started about it even on twitter that many people joined. It seems like, however, that I also started a flame war, unfortunately.
Anyway, let me answer your comments:
Arseny Kapoulkine:
I’ll check if there is really support in D3D for geomerty shader-less stream-output.
This comparison, however, as stated above, does not try to compare GL with D3D from all aspect. This is really about exposed hardware capabilities which is at least one of the most important talks of a graphics API.
GyroTech:
Actually I wanted to name the article “OpenGL vs Direct3D”, but I wanted to stick with the naming convention the mentioned tom’s hardware article used, that’s why I named it “OpenGL vs DirectX”.
xoofx:
1) Yes, D3D did it earlier, that’s for sure, however, with the current evolution speed of OpenGL, this may change to the oposite in the future.
2) To be honest, compute shaders are not a graphics feature, so I’m happy that we have a separate tool for it in the form of OpenCL. And for you to know, we have the same level of integration possibility between OpenCL and OpenGL as we have with D3D compute shaders.
3) Multithreading is more of an API feature than a hardware feature, that’s why it is not discussed and while OpenGL’s multithreading support is in fact inferior today compared to D3D’s, OpenGL in fact did support multithreading since the very beginning while D3D adopted it just lately.
4) You have backward compatibility with DX9 cards with OpenGL as well, that’s what extensions are for. In D3D1x you have also only limited support of the features on DX9 cards, this is no different in case of OpenGL.
C0de517e:
There’s no need to be harsh, I made this article based on request as yes, you would wonder, some people *are* interested what are the hardware features supported by the two major graphics APIs. Of course, there are other aspects of an API that need to be considered, but that’s out of the scope of this article.
1) I did’t say that now gamedevs should start worrying about which API to stick with, of course, but GL is definitely not dead as a platform.
2) While really, there are few games using OpenGL (some of them use it besides D3D), but those are not small ones:
Rage by Id Software
Starcraft 2 by Blizzard
Diablo 3 by Blizzard
and some others also have an OpenGL renderer as well (e.g. Crysis)
Mutwin Kraus:
Thanks for noting OpenGL ES and mobile platforms. Yes, as platforms like iOS and Android became a popular target platform, the amount of gamedevs getting familiar with OpenGL thanks to this may really change both the attitude of gamedevs to OpenGL and the amount of tools that will be available for OpenGL development (which is one of the biggest disadvantages of GL today).
about 7 months ago
This might be out of scope for your article but an important factor in deciding APIs is drivers. The fact is ATI and Nvidia both have very brittle OpenGL drivers. No sane person should touch OpenGL for a commercial game title unless they can use some abstraction layer to filter out the craziness.
about 7 months ago
I don’t think that there are so much issues with ATI and NVIDIA OpenGL drivers. Intel is famous of their poor OpenGL driver support, but this is not the case with the big players.
about 7 months ago
Interesting post. Direct3d will be maybe the prior api for AAA games on windows, But when you want to do apps/games on other plateform the standard is gl. I dont know if it makes sense for MS to not contribute on opengl. Even on the web webgl is already available on modern browser. Not sure there is a war.
Would be curious to see stats about multi plateform games ?
about 7 months ago
for readability, you could repeat the column headers a few times.
about 7 months ago
The table by itself is really interesting but I am not sure using such title was a good idea. The community needs content, it doesn’t need “flame war”
about 7 months ago
You are right, but I didn’t expect that this will happen.
about 7 months ago
Cedric Pinson: for multi-platform games, in terms of sales and popularity, the only games that count are those with console ports. There the decision is easy – it’s usually D3D9 (sometimes D3D1x or – rarely – OGL) on PC, proprietary API on PS3 (that is *not* OpenGL), D3D9-like API on XBox360, proprietary API on Wii (that is *not* OpenGL).
Moreover, on both PS3 and XBox360, the only shader language is Cg/HLSL – so if you want to share the majority of shader code between platforms, you can’t use GLSL or have to use a translator, which is a pretty major obstacle (that, plus the fact that XBox360 has a D3D9-like API, means that the best solution is usually to use D3D9 on PC).
Of course, there are exceptions to the rule – i.e. some major games decide to do a Mac port – but that’s a fraction of the total market.
about 7 months ago
D3D10/11 allows to define texture samplers with-in a shader. No need of equivalent to sampler object.
about 7 months ago
D3D10/11 can sample D24S8 type of texture formats using resource views.
about 7 months ago
Arseny Kapoulkine: Agree but what about the rest of other devices / plateforms, mobile/tablet/browser/macos. I would like to see numbers/stats related to them, because when you target those kind of devices, dx is not a choice. And I guess there is more device that can run games than console, but it would be greate to talk with numbers.
about 7 months ago
Sorry about being harsh, i see that you indeed made a big effort and it is even interesting. It’s the d3d vs ogl title that got me, I really think we should not encourage this war to further spread. Ogl is a capable api, probably a bit worse than d3d (glsl is terrible) but who cares? As i said, it’s not a problem and if it was a problem it’s not about features or design, but market and support.
Again, the table is neat, but the article sparks a flame that will really go nowhere imo
about 7 months ago
Let’s elaborate this a bit, now that I’m on a physical keyboard…
- OGL is not dead.
Of course it’s not! First of all, nothing dies. Fortran is still there (last iso standard is from 2004), software rendering is not dead, hey, there are still crazy people making games for the c64. That’s not the point, and it wasn’t the point of the article you linked. Of course, Linux, Mac, CAD software etc… OGL is an USEFUL api and we need it!
But when people say “OGL is dead” or “OGL lost” or heck even “PC gaming is dead” for what matters, it does not mean it’s erased from the history, it means it’s not really that relevant anymore, it does not compare with its competitor in that given application area.
- OGL has features
Yes of course! OGL is not dead, it’s still being updated, so over the time features are added to it. That’s only -natural- and obvious, no one will really question that, it’s still actively being developed, over the time features are added. But is that the point?
- Why we choose DX over OGL for PC games
Market first of all. OGL made some bad choices (that still show in the current API) that made it lose the battle against DX years ago (see this – http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows/88055#88055). DX9 won the battle, not DX11. Now we have better support, better tools, better drivers… There is really no choice, it’s simply more convenient, not for technical reasons (even if there are also technical reasons, DX11 is really neat, multithreading is really important, CPU performance and so on) but because of the whole ecosystem around the API. And there is not much to debate here, it’s been years that DX on PC for games outnumbers in terms of shipped title OGL by a factor of 100. The only OGL titles that still ship are titles that use legacy ID stuff, basically.
- What about multiplatform
There is no such thing as a multiplatform API. “fast paths” and feature support are usually different enough that if you’re making a multiplatform title, you want your own abstraction over the HW API anyways. And porting a decently done renderer from one API to another is no fuss either, so no one really cares. Yes, if you’re doing an indie title that wants to ship over PC, Mac and Linux then OGL might be something to think about (even if most such titles still ship DX/OGL!) but for any other use case, there is no such thing as a multiplatform API. And no, PS3 does not use OpenGL (it has a lame OpenGL ES layer that no one uses because it’s lame), Wii does not use OpenGL, Android and iOS do not use OpenGL (it uses OGL|ES and even that it’s not really multiplatform, GL|ES 1 and GL|ES 2 are different enough that you want to have an abstraction to cover all your target devices).
- But…
Hey! I’m not saying this because I love DX (I do, but I used to love OGL and hate DX because I hate M$ having to create their own versions of whatever standard there is… then OGL fell and DX rose with a good solid API and I had to admit it was better and started to use it…), and you don’t have to trust my words. Just see the numbers and the games out there. Companies make decisions based on money, in this case it means market and convenience (Dev. time).
DX, for games, clearly won, so why are we even debating about something that is a fact? Again, that does NOT mean that OGL is not relevant or there is not EVER a reason to code in OGL, there are reasons to do so. Just not any for a PC game and not many for games in general. But again, isn’t that obvious?
Hope that’s extensive enough to cover all possible “yes but…” objections
about 7 months ago
Is clear to me that the winner is GL 4.x, f*** DX and Microsoft (And Apple for the matter “Sorry For Steve, was a great Loss” but besides from that, Apple Sucks.).
PS: The Winner is OpenGL.
about 7 months ago
OpenGL is still desirably because it is available for scientific workflows – viewing the protein + ligand in real time regardless of the platform – OpenGL offers that. (Shout out to PyMol for supporting OpenGL years ago).
about 7 months ago
I completely understand your perspective.
My intention with the article and the title as well was to increase the awareness of the industry of the potentials of OpenGL as a first class API for graphics, including games, even on Windows. While I agree that OpenGL lacks of tools and appropriate ecosystem to be adopted by game developers but due to the open nature of OpenGL I would like to encourage the big industry players and the community to fill these holes.
There’s nobody to blame except us about the lack of tools and ecosystem around OpenGL and I thought this article can increase the interest in working with OpenGL as the more people use it, the more tools will be released for it as this is a completely self-inductive process.
about 7 months ago
Honestly, DX should have *huge* green square named “PIX”. Another called “driver support”. Focusing on features that are unlikely to be used, or are likely to be used just once during a project is naive. On the other hand, you are likely to use debugger and profiler everyday. And OpenGL still lacks useful tools. Despite attempts like debug output, OpenGL still communicates with me for most of the time using 4-color diode and H-bomb.
Either Khronos release new OpenGL spec with sane API (DSA and legacy stuff removed for good — “can I change evaluation shader in glBegin” kinda defeats the purpose…) or OpenGL is drown for good. And when I say sane, I mean no monstrosities like glDrawElementsInstancedBaseVertexBaseInstance. Of course good API is just the start, driver support and tools are even more important.
I doubt if iPhone/Android development has any significant impact on PC/console gamedev. How many AAA games (or even all Windows games, or even all Windows apps…) use Objective-C and/or Java? Also, most iPhone folks are more than happy with existing 2D frameworks.
Last but not least: I am an OpenGL developer. I would love to see OpenGL win this war. But this is impossible at the moment. Rage is the only AAA game that uses OpenGL and still has problems, despite dedicated drivers. And that is id Software. What about smaller developers that are unlikely to gain IHV attention?
about 7 months ago
It is sad that you feel so. I’m not a professional OpenGL developer, actually I’m rather a hobbyist and AMD corrected already several bugs based on my reports and even implemented a new feature, namely AMD_multi_draw_indirect, so gaining IHV attention is up to you.
And one more note about iPhone/Android development, I feel sorry that people see it that you can only develop in Objective-C/Java. I do make my next game for both platform using C++ so what?
about 7 months ago
I am well aware that you can use C++ on iOS and Android. But it actually diminishes your argument ever more: people use cross-platform frameworks/engines and do not deal with low level. If they don’t need Obj-C/OpenGL to program on iPhone then iPhone does not promote Obj-C/OpenGL. And don’t forget that performance-wise, mobile OpenGL is more similar to Voodoo2 era than modern OpenGL
about 7 months ago
Okay, then are you aware of that you can use OpenGL from C++ on iOS and Android?
I wouldn’t say mobile OpenGL is more similar to Voodoo2 era neither from performance nor from feature point of view. Did Voodoo2 support shaders, shadow mapping, etc? These are all viable on the newer mobile GPUs.
about 7 months ago
Actually I would rather compare the newer mobile GPUs to the first OpenGL 2.x capable GPUs like the Radeon 9700 or the GeForce FX.
about 7 months ago
it is because it support opengl es 2.0
about 7 months ago
I haven’t seen many mobile games with advanced shaders or realtime shadow mapping. Actually, most games use ES 1.1 profile for performance and greater compatibility. It will take some time to get rid of old mobile hardware, just like on PCs.
I’m just saying that people using Objective-C and OpenGL on iPhone doesn’t equal to people using Objective-C and OpenGL on Windows, because there are alternatives for both.
about 7 months ago
nop it does not equal but it talks about OpenGL used on other plateform than windows/console and it makes senses because this world exists. Advanced or not you dont have choice to use hardware without opengl on this plateform. The use of opengl es 1.1 or 2.0 is just a decison if you want to support old hardware or not. 2 years mobile are able to support opengl es 2.0.
but it’s not the point. You just need to access hardware with an api on mobile.
And you are right mobile will not be able to run Crysis on modile yet
about 7 months ago
As a person who asked about this article, I’m satisfied.
I also understand title. I’ve read mentioned article, and it was about OpenGL 3.0 delivering too little too late. So replay comparing hwd features coverage title is quite good!
Can you add link to materials about DX11.1 features? Are there any official MS info about it?
about 7 months ago
Yes, there is a list of DX11.1 features published by MS but it’s preliminary and is subject to change:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh404562(v=vs.85).aspx
about 7 months ago
D3d10/11 is capable to cast a existing texture’s format,
with resource views. In Ogl we have to copy it with pbos.
about 7 months ago
Thanks! I’ll add that to the list.
about 7 months ago
OpenGL can resolve partial shader interface matching
about 6 months ago
DirectX? Peoples still using that?
Honestly.
DirectX is only popular in PC AAA titles. B and Casual games are using OpenGL for oblivios reasons (better compatibility with other platforms). Nobody realy uses DirectX on pc, except the AAA, wich gives LESS than 5% of the total game market! …and DECRASES brutally in every year since 2005. The other platform where directx is used, is the xbox360. wich is not so tragic like pc dx share, but still… OpenGL and derivations of OpenGL simply dominates the whole game industry.
Imagine the most popular games, all of them is some 2d crap with minimal 3d. glvertex3f, and thats all. Game developers want to write games, not fucking nuclarphisic simulations. IMHO DirectX 11 is a mistake. NOBODY wants to code even the fucking alphablending algorythms. Exept for some special effects. Graphics API-s should give a cool subset wich developers can use to create they games – and not to force developers to create applications around retard ideologies. (also stands for ogles2 currently)
DirectX 11′s market share is undetectable small. Microsoft even made that mistake that they not released it for Windows.
DirectX is a disaster, i would not write any games based on it.
about 6 months ago
*they not released it for Windows XP,
about 6 months ago
Geri: sorry, but your argument is totally pointless.
What decreases is the market share of AAA titles and yes, this is somewhat advantageous for OpenGL, but it is not about Direct3D but about the popularity of AAA titles in general. Though, have to mention that the greatest tech innovations are still done in AAA titles, though gameplay is a different story.
You also mention the Xbox360 where you say “dx share is not so tragic like in case of pc”. Well, that’s pointless as well as there is no OpenGL support on Xbox360, it is D3D-only.
Another thing that you’ve mentioned “glvertex3f”, i.e. immediate mode. Well, no sane person uses immediate mode in new code bases that were started in the last decade, simply because it just has awful performance. It is not a coincidence that neither OpenGL ES (neither version 1 or 2) nor modern OpenGL (and here I’m obviously talking about OpenGL 3.x+ core profile) supports immediate mode. Actually the fact that still many OpenGL coders use immediate mode for rendering is what makes look OpenGL ancient and deprecated and I would really like to ask all these people to stop spread the word that OpenGL is cool because it has immediate mode and fixed function stuff. Those are the ones that are deprecated in all modern favours of OpenGL.
While I’m an OpenGL supporter, saying Direct3D 10 or 11 is a mistake is just pointless again. Every Direct3D developer who cares just a little bit about simplicity, maintainability and performance has to switch to D3D10+ and abandon their D3D9 code bases.
Your problem, and in general many other developer’s problem who dislikes D3D10+, OpenGL 3+ and OpenGL ES 2 is that you cannot see that modern graphics APIs are about exposing the hardware capabilities and just allowing you to make everything however you wish. Yes, there is no magic switch to turn on lights, fog and stuff like that but you can do much more than with fixed function and this is way it should be done.
One more thing related to your comment is that you’ve mentioned that WinXP doesn’t support D3D10+. Well, actually WinXP is no longer supported at all by MS, so that is totally pointless as well. Also, the fact that D3D10+ is not supported on WinXP was not just decided arbitrarily by MS but because the whole graphics card driver model changed from XP to Vista and that is what is required by D3D10.
about 6 months ago
Almost nobody uses opengl 3 and above. (i am sure you can google 1-2 modern game that uses, but thats all), and nobody uses dx10/11, except the aaa titles.
Everybody uses the old good apis, such as the traditional opengl, or rarely directx9. Just go to indie gamedev sites, and check it. For example, check sourceforge, for example the first 2000 result. And count how many opengl and d3d based games are coming. And then check, how many actually uses features shaders, or even VBO. I alreday did it in the last year. You will be suprised. Ofc xbox360 is d3d only, this is why i mentioned it. I want to stay objective
I totally understand them, they are right. I also maintain the point,(even if my softwares using vbo, capable to use shaders in some situations, etc) that game developers want to create games. Why they should understand the working of the hardware? They want to do they own games with minimal possible work. They are not hardware engineerers, they are game developers. This is the explanation, why opengl3+ and dx11-s reputation is so tragic, becouse they cannot satisfy this needs.
about 6 months ago
The fact that most idie developers are still using DX9 and legacy OpenGL is because they weren’t fast enough to do the transition. Actually, a lot of indies did move to DX10 and OpenGL 3. Just a single example is the indie Leadwerks Engine that is going to release their third version engine using OpenGL 3+.
I’m not saying that we should throw away every single line of code that is available that uses DX9 or legacy OpenGL, but a new project should definitely focus on DX10+ and OpenGL 3+, and to reasure you, they actually do.
about 6 months ago
Virtually *all* professional casual games use DirectX 9.0 on Windows. Target audience largely use old Intel integrated graphics or ultra low-end dedicated chips with drivers not updated since forever. id Software can make you download new drivers in order to play Rage, no casual publisher is going to do that. Most “indie” games use DX 9.0 as well, because that’s what popular engines (UDK, Unity etc) use as backend on Windows.
Saying that, DirectX 10/11 is niche as well. Number of DX10/11-only games is very small, number of DX11-only games is even lower (are there any?). Unless you drop legacy stuff (in this case DX9), benefits are very limited.
about 6 months ago
Also, software engineers not knowing the hardware they work on are simply incapable of providing the best performance (and you don’t need to be a hardware engineer to be able to understand how can you the hardware in the best way).
Finally, game developers usually have special roles as well. As an example, a rendering engineer in a game development team has to know the hardware and has to use it in the best way possible. Of course, game logic writers don’t need such knowledge, but in case of indies where the teams are smaller (sometimes only a single person) knowing all the aspects of the game development is even more crucial.
about 6 months ago
Tomasz, so your suggestion is that we should stop all kind of innovation and stick with DX9 and legacy OpenGL because that’s enough for everything?
Yes, casual games may jump on the wagon later than AAA devs but this is just a matter of time. Sooner or later everybody will have to switch to up-to-date technologies because OpenGL 3+ and D3D10+ is the future. The fact that some vendors (*cough* Intel) don’t provide proper drivers does not mean that we should stick with old technology.
about 6 months ago
It’s just technical POV (use cool, new technology) doesn’t match business POV (target as much people as you can). They both agree on “create best product possible” but the question is “does new technology really matter for end-user?”. Crysis 1 runs on DX 9.0 and after almost 5 years is still one of the best looking games ever. What is the point of using new technology and requiring more powerful hardware if your game looks worse that that?
about 6 months ago
And previous post was largely a correction of “Casual games are using OpenGL for oblivios reasons” which is BS (on Windows).
about 6 months ago
Aqnuep: game developers does not want to get the best possible performance. Those are the body builders
Game developers want create games, and judging from the numbers of the total gamedev industry, they finding the legacy opengl as the ultimate solution.
Yeah, ppls who wants to create rendering softwares, can benefit from the possibilities of the modern graphics API-s, but thats a different story (aniway, opengl dominates there too)
about 6 months ago
Tomasz: stating that there is no “better looking” game than Crysis 1 is stupid. There are, in fact Crysis 1 also looks better if you use the D3D10 renderer
Also, sometimes using new technology means requiring less powerful hardware. Just a few examples of such technologies: texture arrays can lower the CPU requirements of a game, so as geometry instancing. New technology means new technology, not horsepower.
Geri: a developer who doesn’t want to get the best possible performance is a bad developer. We, as software developers, are dealing with limited amount of compute power, nobody should waste any just because it doesn’t matter. This is why the market is filled with huge amount of badly written casual games that simply require quite a strong computer but the quality does not justify it. This is why AAA devs will be always the key innovators from technical point of view because they reach the upper limits of the hardware because they have to, not just because they don’t care.
about 6 months ago
One final note because we went a bit off-topic. This article is not about game development and especially not about the tons of casual games out there. It is about current state of real-time rendering technology, nothing more or less.
about 6 months ago
If a developer creates a software (for example, a graphics software, and currently the most popular things that using graphics is the tons of the casual games out there, so its a good point of view), has to care about a lot of things. The most of it is economically thing, and not technically related.
-get an idea
-create a conception around it
-create a game that everyone can play
-most possible ppls to play with it
-find the easyest ways to share it
-with the way, how to made it with most possible minimal work
-produce the thing within the shortest possible time
and the most technical things are
-ability to port the stuff to multiple platforms if possible
-keeping the source in the simplyest possible levels
etc etc etc… writing an architecture that can spin the most possible performance out from the hardware, is a very tertiary factor in almost all cases.
as the saying goes:
MY SERVICES ARE THE BEST.
-Cheap
-Fast
-Good quality *
(*you can choose two)
about 6 months ago
I’m not saying that there are no “better looking” games than first Crysis (esp. given that quality is subjective). What I’m saying is DX10 is not a huge leap in graphics quality for end-user (gamer). In fact it quickly turned out that you can enable almost all DX10 features in Crysis in DX9 mode as they were disabled for pure marketing reasons. And if it isn’t a huge quality improvement then you must very carefully consider is it worth using at all.
For average casual game the benefit of using DX10+ (or OpenGL equivalent) is non-existent. Nobody sane would trade half (or more) of userbase for features he doesn’t need.
For AAA game it’s just a matter of calculation what is more viable. And of all DX10/11 features I believe that good multithreaded rendering is the most important bit which could really improve performance. And well, it could be a killer feature and yet no OpenGL release addresses that.
about 6 months ago
I think you totally don’t see the point:
New features are not just about eye candy and new hardware is not just about more horsepower. It’s optimization. Multitreaded rendering is a cool thing and I hope we will see better support for it in a new OpenGL version. Though have to mention that OpenGL had multithreaded rendering way before D3D had.
If we just talk about what can be done with a GPU, actually you could do almost the same things with a DX9 level GPU as you can do it with a DX11 level one. The difference is performance. Not just because newer cards have more cores and higher clocks, it is because of new features.
So back to optimization, just give you a few examples:
1. Before instanced rendering, you had to manually do it at the client side, so the CPU time required to draw 100 objects without instancing is 100 times bigger than drawing the same 100 objects with instancing.
2. Before texture arrays, you could not batch up multiple objects that had different textures. This, again, meant that drawing 100 objects with different textures could take 100 times more time on the CPU side than if those would be put into a single batch thanks to texture arrays.
3. Before geometry shaders and layered rendering, you could render a reflection cube map only with six scene drawing passes and that’s exactly six time more CPU time than that is required when you have geometry shaders and layered rendering.
There are a lot of other use cases that justify the existence of new features. Those who are not familiar with them cannot see how important are these. They just see the games and that nice games are made with DX9 as well.
Okay, yes, maybe you can make the very same thing with DX9, but your code will be suboptimal and it will require a lot stronger CPU and maybe a stronger GPU to handle it. So we ended up with the following result: you need a stronger computer, so then what is the point of using DX9 if it requires even a stronger GPU than it would be required if you would use DX10? Btw, DX10 also supports (to a certain level) DX9 GPUs as well. The same goes to OpenGL, you have all the features exposed that your GPU is capable of, no matter which core version you are using.