Jump to content
  • Advertisement
Sign in to follow this  
blueshogun96

OpenGL The API similarities between D3D12, Vulkan and Metal?

This topic is 802 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The reason I'm asking this is because I plan to update my engine to support Direct3D12, Vulkan, Metal and OpenGL 4.5 via GL_NV_command_list only.  Right now, my engine supports Direct3D11 and core OpenGL (ES is broken right now), and since so far these APIs seem to be very different than their predecessors after taking a quick look at the basics so I want to write a new interface to handle it... similar to how Direct3D keeps track of it's interface versions.

 

/* Higher level rendering class */

class IKeRenderDevice;

class IKeGeometryBuffer;

 

/* Lower level rendering class */

class IKeRenderDeviceEx;

class IKeCommandBufferEx;

 

What am I asking?  I'm asking how similar, if not, how different are each API from each other?  What I should probably do first is start working on an API as I write some basic code to get acquainted with each API.  Start with a triangle, then add a texture, etc. and design my render device and command buffer classes as I learn.  But the more I learn, the more I tend to run into some gotchas that make it a bit more of a challenge to write a universal API that the user can choose to your liking.

 

If you're curious about my engine so far, you can take a look here: https://github.com/blueshogun96/KunaiEngine

 

And please, don't tell me that I should use UE4 or Unity instead because it's a "waste of time".  That's not constructive and I get tired of arguing this all the time because for me, the benefits of having a custom engine greatly outweigh paying for a pre-built closed source one.

 

Thanks,

 

Shogun.

Share this post


Link to post
Share on other sites
Advertisement

I'd argue that it really depends on who your target is when it comes to the level of abstraction. If I open up an engine whose finest granularity is geometry, does that mean I'm precluded from doing my own custom compute tasks? Welp, on to the next engine then. 

Share this post


Link to post
Share on other sites

I'd argue that it really depends on who your target is when it comes to the level of abstraction. If I open up an engine whose finest granularity is geometry, does that mean I'm precluded from doing my own custom compute tasks? Welp, on to the next engine then.


Well, two things.

First... yes, no one engine meets every single possible use case. There's a reason that the entire industry hasn't just standardized on a single universal engine already. :)

Second, you're perhaps missing a key point: the abstraction should be the renderer itself. The renderer is where you add graphics features. It doesn't make sense to have your graphics system provide yet another level of abstraction just so that the gameplay layer can (poorly) implement custom rendering features. If you need to add some compute effects or the like, you add them in the renderer, not above it. Non-graphics computer is another story, and arguably an orthogonal one. That is, your abstractions for non-graphics compute should not be the same abstractions you use for graphics as otherwise you end up with physics/AI/whatever having a hard dependency upon your graphics APIs, which is just bad architecture.

Share this post


Link to post
Share on other sites
BTW what is the actual cost of wrapping an api inside a virtual class?

On the first hand Vulkan and dx12 are designed to make you bake as much state change as possible in bigger set like pipeline state or descriptor table or command list. There is thus less api call done which translate to less virtual call made for a close enough api.
On the second hand the point of these api is to lower cpu overhead as much as possible ; several Vulkan functions even take array of parameter structure to build multiple api object within a single function call (to write descriptor call, create pipeline state,...). If the cpu overhead reduction makes possible to notice a perf difference when removing around 10 function calls per draw call then I would rather avoid the cost of vtable indirection if possible.

Share this post


Link to post
Share on other sites

On the second hand the point of these api is to lower cpu overhead as much as possible ; several Vulkan functions even take array of parameter structure to build multiple api object within a single function call (to write descriptor call, create pipeline state,...). If the cpu overhead reduction makes possible to notice a perf difference when removing around 10 function calls per draw call then I would rather avoid the cost of vtable indirection if possible.

 

Those functions accept multiple structures/objects to avoid having to run internal code that is orders of magnitude more expensive than simple function call overhead.

If you use the API correctly the overhead from vtable indirection is virtually nonexistent (and if you don't you're gonna be bottlenecked by something else long before).

Share this post


Link to post
Share on other sites

BTW what is the actual cost of wrapping an api inside a virtual class?

Virtual calls are pretty damn cheap on x86/x64 CPU's (others, not so much)... You probably won't even be able to measure the cost :wink:

 

but you don't need any virtuals to make an API wrapper. You only need virtual functions for runtime polymorphism -- i.e. if your game needs to be able to use D3D12 and Vulkan at the same time via the one interface, then yes, you need virtuals (or some other dynamic dispatch mechanism). But you never need to use multiple graphics APIs at the same time, so you can use compile-time polymorphism instead.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!