Jump to content
  • Advertisement
GuyWithBeard

OpenGL Design advice for a front-end for modern graphics APIs

This topic is 559 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

I am looking to replace my current DX11-only renderer with something better and to make it easier to support many graphics APIs I am writing a common "front-end" API for the graphics APIs I want to support. The renderer is layered and looks a bit like this (I assume this is a farily common way to organize things):

  1. First there is the high-level renderer, ie. the API that the rest of the game communicates with. It contains concepts such as scene-graphs, meshes, materials, cameras, lights etc.
  2. Below the high-level renderer sits the front-end API for the actual graphics APIs we want to target. This is an API that contains (or can emulate) all important features of the graphics APIs, such as devices, textures, shaders, buffers (vb, ib, cb), pipeline state etc.
  3. Below the front-end API are the actual graphics APIs (DX11, DX12, OpenGL, Vulkan, Metal, libGCM etc). These are loaded in as plugins an can be switched during runtime.

I started writing the front-end API with the mindset that I'll target DX11 first and perhaps add DX12 and Vulkan support later. However, this seems to be a very bad idea especially since I have the rare opportunity to rewrite my whole renderer without having to worry about shipping a game right now. Most people seem to agree that it is better to write the front-end to look like the modern APIs and the emulate (or in some cases simply ignore) the modern-only features for the older APIs.

My question is this: What features of the modern APIs should I expose through the front-end API? I would like to make somewhat good use of DX12 and Vulkan so consider those as the main back-ends for now. In my current version of the API I already moved all state into a PSO-like object which will be the only way to set state, even on older APIs. However, after looking into DX12/Vulkan a bit more (note that I still only have a few hours worth of experience with either) it seems that there are other new object types that ideally should be exposed through the front-end, such as command lists, queues, fences, barriers, semaphores, descriptors and descriptor sets + various pools. What about these? Anything else? Does it make sense to try to wrap them up as they are and can DX12's concepts be mapped to Vulkan's concepts or do I have to abstract some of these into completely new concepts?

Thanks for your time!

Share this post


Link to post
Share on other sites
Advertisement

Thanks Hodgman for the detailed response! Incidentally I found an interesting video on Vulkan yesterday at: 

Especially the first and last talks are very interesting. Around the four minute mark there is a slide on what Xenko's renderer exposes. Seems like they went with exposing descriptor sets too, but don't really explain why, just "you can't get around it", and that they went with the Vulkan approach of descriptor sets rather than the DX12 approach (which I cannot comment on at all yet). I also very much like the PSO approach even on older hardware so I think I am going to make them first class objects in the front-end too.

Share this post


Link to post
Share on other sites

Seems like they went with exposing descriptor sets too, but don't really explain why, just "you can't get around it",
Yeah, "we can't get around [exposing these as first class concepts]" is an interesting throw-away... I guess it's in the context of wanting to redesign as a "next gen" API.

I mentioned above a way to get the benefits of PSO's without making them first class -- a stateless API built around "draw items" is analogous to PSO's, but doesn't have to expose a PSO-like interface. You can expose a D3D11 or even D3D9 style interface to the draw-item compiler.

To implement a D3D11 style resource binding model, you can create a non-shader visible descriptor heap, and pre-create all your resource-view objects on it (similar to pre-creating D3D11 resource-view objects). Then at draw-submission time (or draw-item creation time), you can copy the sparse collection of views from that non-shader-visible heap into a contiguous table in a shader-visible heap. You manage those tables with a ring-buffer so that you can dynamically create them every frame. Doing it this way won't get you to full benefits of letting the user create static/reusable descriptor tables, but will still be faster than D3D11/GL :)

I actually support both -- my "resource lists" are a simpler abstraction than the entire descriptor model (which is quite low-level and exposes many tricky details, such as CPU<->GPU data synchronisation to its users...), and at creation time my users can specify whether they want an immutable one or a mutable one. Immutable ones can be mapped to pre-created/reusable descriptor tables, while mutable ones can use something closer to the D3D11 emulation system described above, where the tables are dynamically constructed at draw submission time.

Share this post


Link to post
Share on other sites

I wonder how hard to would be to just use Vulkan, and then make a Vulkan -> D3D12, or Vulkan -> D3D11, etc... implementation.  I wonder if anyone's working on that...

Share this post


Link to post
Share on other sites

I wonder how hard to would be to just use Vulkan, and then make a Vulkan -> D3D12, or Vulkan -> D3D11, etc... implementation.  I wonder if anyone's working on that...

If your interface is well designed it would be trivial.  In the engines I've written it would require writing either a plugin or a new set of .h and .cpp files to implement the new API in wrappers and away you go.

Share this post


Link to post
Share on other sites

I wonder how hard to would be to just use Vulkan, and then make a Vulkan -> D3D12, or Vulkan -> D3D11, etc... implementation.  I wonder if anyone's working on that...

If your interface is well designed it would be trivial.  In the engines I've written it would require writing either a plugin or a new set of .h and .cpp files to implement the new API in wrappers and away you go.
I think he means emulating the Vulkan API as is, on top of other APIs.
Sure, it's possible, but performance would not be great. Real ports to each API are best for performance.

Looking into the future, implementing old APIs on top of Vulkan is totally feasible though, and would be a cheap way to port say, D3D11 games to a new platform.

Share this post


Link to post
Share on other sites

  • 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!