11
$\begingroup$

Are the differences between these two APIs minor implementation details that mean once I have learned one I can use it for everything? Or are there reasons for learning one rather than the other if I want to be able to use it in general without having to relearn another API in future? Is one or other more general?

In particular I would like to be able to write for any graphics card, so code is not restricted to only running on a particular manuafacturer's cards or a specific model. I'd also like to be able to write code that still works in the absence of a graphics card (albeit slower).

Is there a difference in how portable code will be across different platforms (operating systems/architectures)? I'm interested in the availability of other libraries that work with these, and whether one or the other leads to fewer licensing restrictions in its wider environment. Anything measurable that would make a difference to whether one of these could be the only one I learn without restricting me.

$\endgroup$
  • 2
    $\begingroup$ ratchet freak's answer is a good one. If you want to learn Direct3D you can read my free book "The Direct3D Graphics Pipeline". The API details are mostly Direct3D9, but the concepts are the same. The thing is, the concepts for programming 3D graphics haven't really changed at all since the late 1960s. The APIs for expressing those concepts have gotten much smarter. $\endgroup$ – legalize Nov 3 '15 at 23:38
9
$\begingroup$

I don't think it matters much, which API you want to use when leaning to "program graphics". The more important things to learn are the typical concepts you use when working with 3D scenes. For example you want to learn how to write a simple (and later more sophisticated) Scene Graph. These concepts are much more important than the specific API method names you have to call.

Compare it when learning how to write programs. If you are quite good at writing programs in e.g. Java, you won't have that much trouble learning C++, Objective-C, Swift, or some other object-oriented language. Because it's the concepts and the thinking which you learn.

The choice between OpenGL, Direct3D and Metal is primarily the choice, which operating system you target. Direct3D is primarily available on Windows, Metal on OS X and iOS, and OpenGL is supported on most systems including OS X, iOS, Windows and Linux.

The graphics card probably has little to no influence on this decision as I don't know a card that supports only one or two. If you have no dedicated graphics card, then rendering in real time will be a problem soon. Although a Intel HD Graphics and the AMD companion can already do quite much.

So, choose your platform.


Disclaimer: As of now, I did neither use Direct3D nor Metal.

$\endgroup$
  • 2
    $\begingroup$ > "If you are quite good at writing programs in e.g. Java, you won't have that much trouble learning C++" — this is not true. Everybody will have colossal amounts of trouble learning and using C++. Comparing it to Java or any other safe language is completely inappropriate. For other languages you listed (Objective-C, Swift, or some other object-oriented language) that statement is mostly true, though. $\endgroup$ – Sarge Borsch Jan 14 '17 at 13:19
9
$\begingroup$

We are currently in a transition of API paradigms.

The old school method of binding buffers, uniforms, attribute, layout and programs as (implicit) global state and dispatching draws with that state is common across D3D11 and OpenGL. However it has a large amount of overhead (in verifying state and not knowing what the program wants to do until the last minute). They are also not thread safe (for the most part).

This is why new apis have come up (or are coming soon) D3D12, vulkan and Metal being the most prominent. These APIs give more control to the program and lets it declare in advance what it want to do using command buffers. They also let you manage your own resources (vertex data, textures, ...) much more directly. Using them with multiple is much more straight forward.

The choice between old and new is based on how well you can manage the video memory you allocate and build the command buffer.

  • If you want something that "just works" even on older hardware then the old school APIs are better; they also are better known and you will get more help on them online.

  • On the other hand if you can handle the asynchronous nature of dispatching commands and don't mind having to track all the buffers you allocate. Then the new APIs may be something for you.

$\endgroup$
  • 6
    $\begingroup$ The new explicit graphics APIs aren't really designed for consumption by the average graphics programmer, they're more for the people doing infrastructure work in engines, or for those who really need the performance. They give you a much bigger gun and point it right at your foot. $\endgroup$ – porglezomp Aug 21 '15 at 16:07
3
$\begingroup$

I do not personally think it matters much. Just pick one that suits your project. I have used both D3D and OpenGL in the past. It is the concepts that matter. Whichever you grab, you need to understand (for example):

  • What textures are and how they are used by GPU.
  • Basic concepts of Graphics Development (Vertices, Primitives, Fragments, etc.)
  • How does the camera system work (MVP matrices in OpenGL for example).
  • What shaders are and how to use them properly.
  • How different a GPU works versus the CPU on your machine.
  • What are the differences between GPU's memory model and CPU's memory model.
  • What should be done on CPU and what should be offloaded to GPU for processing.

As others mentioned here, we are in the middle of a transition to a new set of APIs (Vulkan, Metal, etc.) so at this point if you are completely new to Graphics Development, probably focusing on GLSL is a good idea since Vulkan is going to take advantage of it as well.

Regarding portability, D3D is Windows only (There are rumors that the Wine project is trying to get D3D working under Linux but nothing feasible so far). OpenGL is cross-platform. If you want to go mobile, then OpenGL ES is an available option. Of course both OpenGL and OpenGL ES have different versions which are not supported by all platforms.

At the end of the day, all APIs access the same hardware on your machine, it is just a matter of "how" they access it.

$\endgroup$
  • $\begingroup$ Direct3D is also what you would use if you're programming for any of the Xbox consoles. $\endgroup$ – legalize Nov 3 '15 at 23:37
  • $\begingroup$ What do you mean by "nothing feasible"? Wine runs hundreds of D3D-based programs without problems, and has done so for years. Of course there are bugs and unimplemented parts, but that doesn't make the whole API unusable. $\endgroup$ – Ruslan May 4 '18 at 16:45
0
$\begingroup$

I'll say a few words about rendering without graphics cards.

Niether OpenGL nor DirectX really need a graphics card. An implementation may be fully software accelerated.

For OpenGL in Linux there is Mesa software rasterizer. In my experience it works ok as long as you don't push it too hard combining weird features (display list + indexed vertex arrays). I imagine their list of actual bugs is mile high. Make sure to do continous testing!

I have less experience using OpenGL in Windows. Edit answer if you know anything!

DirectX SDK is delivered with a software rasterizer called "reference rasterizer". It is mostly for debugging in my opinion but I know of at least one friend using the reference rasterizer when developing DX11 on a DX10 only capable laptop. As mentioned in other answers DirectX is Microsoft only.

$\endgroup$
  • $\begingroup$ In my experience using an integrated graphics card should be good enough for most OpenGL development on Windows, just make sure it supports a recent OpenGL version. $\endgroup$ – akaltar Oct 24 '17 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.