[DirectX 12] Backend

[wh1t3lord]

Introduction

So it is a new backend from me and it's DirectX 12 for Microsoft NT platforms (>=Windows10).

The library comes to a stage that it is needed to provide more user friendly interaction between end user and library, what relates to rendering backend is a simple and naive integration like in the popular library ImGui by Ocornut where user already has an integrated backend and they need to pass an initialization structure with all required parameters.

Well I will describe more detailed this chapter but for now I just leave this message in a such poor state, because for now it is a reminder for me to finish this work and move to Vulkan implementation.

Backend architecture

I set a straight aim to provide an efficient and optimized resource management and provide to user the low level settings of resource allocation. I mean that backend strives for being simple from user's side (in terms of how to set things up) and from another side it optimizes in all ways possible.

Buffer management aka geometry

About buffer management the library allocates one buffer and utilizes all its space the offset calculation is based on this offset allocator implementation by sebbbi (see sources, MIT license).

But if buffer is out of memory or offset allocator can't allocate the required space it will allocate a new buffer.

And rendering system tries to deallocate the buffer if it is not used. (in optimized way of course)

For now I tested with a really small sized buffers like less 1Kb and it was stable, of course it is not optimal settings due to high allocation of buffers and defragmentation of GPU's memory. By default I picked an optimal size that for most cases should be enough for using, but as I stated earlier user has a right to change that allocation size on initialization stage.

Texture management

DirectX 12 has two types of allocation of textures.

First one is to send texture to GPU as a single buffer, like if it is 4 Mbs then we send 4 Mbs as one single buffer. It is straight and simple and generally used among all modern GAPIs.

But there's a second variant for allocating textures aka placement PlacedResource (see link). That means you can allocate multiple textures into one buffer like you allocate one big buffer and suballocate space for textures thus it is like you "placed" those textures into one buffer. But that works only for not big sized textures that less some specific size, because in official tests it won't give any profit from performance, but still useful for rational resource management.

So based on texture size and its calculation the system tries to choose best way for uploading it.

As a conclusion I tried to make backend that utilizes all memory efficiently as much as possible and make all possible to fill all buffers and buffers for textures in most optimal way that user doesn't need even think about it at all.

Warning

Since we formally force people to use our backend then I don't see any motivation to help to people who make own backends based on our implementations and there's a vital reason for this, because it is better to have "one" (not in directly meaning) backend that be tested on many devices across different OSes than having some custom backends that can't be well tested at all. It is important warning for all users who have tendency to make own wheel ignoring obvious sane way of living.

I need to say that I tried to keep things without breaking changes at all, like if you want to initialize RmlUI as you did before you just don't pass an init structure and from function calling it is just a default argument that you don't specify thus nothing is changed/broken.

But we will (at least me) accept all incoming that relate to backend and it's working state on different graphics cards and OSes for @mikke89 I suggest to create template issue that has the following form (just as an idea):

If you have trouble with rendering backend

Specify GAPI

Blah 12

Specify graphics card's driver

Blah 12.451.16 oct 2023

Specify graphics card

Blah RTX 24000

Specify OS

Blah 13

Specify version and commit of RmlIUI

6.0 d23a3da

I guess after finishing "modern" backends we will boost for some time the popularity of library but at the same time amount of running tests and examples would be high since everyone can easily integrate the library... :D

For now I am making support for multisampling feature and I hope I will finish this work till August.

[mikke89]

Thanks a lot for working on this, a DirectX 12 backend will be a very welcome addition! Let me know once you feel it is ready for review.

I quite like the initiative for introducing such a "renderer initialization" type that provides the user's own parameters. Although, I'll have to think a bit more about this, and how it fits into the library and how it integrates. I think it's important to keep it so that we don't take control over the main loop and event system, to ensure that the library plugs in to their existing infrastructure. Which is why we currently say that users should copy the backend itself into their own code (as opposed to the renderer and platform parts of the backend). But at the same time, we want to make it easier to get started for users that perhaps only want to provide their renderer details, but otherwise use the backend as it is. This generally looks like a nice opt-in solution that could be helpful in many use cases, but I'll need to take some more rounds and think about it.

Regarding issue templates. I actually quite like the informal nature of giving users a blank slate to describe their issues. I think that has some value as a community. Of course, I understand that with growing number of issues, some system like this could be helpful to speed things up, but I don't believe this is an issue for us at this point. I generally find that users are good at describing their issues. Regardless of templates, there will always be some times where more information is necessary. And that is perfectly fine in my view, there is also some value to this interaction as well. So I would prefer to keep this as it is.

[Paril]

Regarding issue templates. I actually quite like the informal nature of giving users a blank slate to describe their issues.

Just wanted to chime in on this one and say I agree; overly-complicated forms and templates have dissuaded me from making issues on other projects (same for something like stalebot, which I hate even more). I understand why some people use them but I find most people are pretty good with issue-posting when you don't give them any instructions at all.