Vulkan

[wh1t3lord]

We are really close to finish this GAPI implementation!

Current state is:

• General implementation (rendering, initialization, destroying, etc);
• Implement static resources for GPU side;
• Implement dynamic resources for CPU side;
• Implement releasing textures method;
• Improve performance, because current implementation of RenderCompiledGeometry works slower than OpenGL versions;
• Fixed texture syncronization issue;
• Fix stencil rendering;
• New feature about resizing for RmlUi;
• All examples work well.

Continuation of #236.

[mikke89]

Thanks for continuing this work!

I think we also need to figure out what to do with textures. Currently they are not released until shutdown really. This causes trouble with e.g. the lottie sample which crashes after a few seconds since that one keeps generating new textures in a loop. This could in principle also be a problem when using a lot of different font styles, as that would also generate a lot of textures.

[wh1t3lord]

"Implemented" static resources.

But there is a one thing... Still we have new and delete operations that will cause by containers. I minimized and used all things in fixed-size manner (like we developed for emdedded devices, IMO it is just a good approach for developing things on C++), but std doesn't provide a good solution for creating std::queue with fixed-size.

As possible solution is to use boost::circular_buffer for replacing std::deque, but still it is not a sane variant, because we don't need to use boost for library.

To sum up, all things like buffer handling, handling on cpu side data (like Rml::Containers) all goes with fixed-size manner and it is really good, because we removed all explicit new and delete operations at all. But still it is reasonable to achieve full pre-allocated behavior for all system (renderer at least, so what I did now).

I don't call for implement that for internal stuff, like how you manage your resources for UI elements and how it calculates, but still it would be a great achievement in UI development for C++. The library just uses only static, pre-allocated resources for everything, looks like 90s where you have only fixed, limited memory and you need to survive somehow and for user it is great to specify how many real memory he needs for executing his application.

Anyway, there's one thing to deal with it is to understand why invaders don't work, and why the transform example has strange execution of animation (?), because when I use fast move slider animation plays, but if I stop the picture freezing.

I don't understand why, but RenderDoc probably will say to me what's wrong. I hope there's no GL code or something else in animation implementation, because it can interrupt Vulkan execution.

Hope to finish this until next weekends.

[mikke89]

I see that animations are working now too, good job!

In my view it is more important in a sample renderer like this that the code is easily understandable, rather than trying to come up with clever (CPU-side) memory allocation techniques. Users that care a lot about memory allocation will mostly likely have their own memory pools they want to integrate the renderer into in this case. As you say there are no great standard libraries for these things, so I'd prefer we just used std::vector, or new/delete when you need pointer stability. At least until profiling shows significant performance overhead.

Furthermore, rather than having a fixed upper limit on resources I think we should rather allocate new resources as required. I believe a sample renderer should be general enough to work in all situations. If users want to cap resources for their situation that is fine and they can do that with their own modifications.

Keep up the good work :)

[wh1t3lord]

@mikke89

It's actually good to have two implementations. One "naive" one that shows extremely simple resource management logic (using your OpenGL as an example) and on the other side to have an implementation that is not simple. And this is important, because most users will expect a "perfect" implementation that will immediately be both super-optimized and generally that everything will work well, but in most cases, no one of course obliges us to make examples of integrations at a very high level. Because everything is learned by comparison, for us, if we really develop as if we were doing it for embedded devices, then it's just a plus for us, nothing more.

I wanted to show the users how you could develop your Vulcan renderer in the best way, and give the basic ideas, which are laid down in the implementation, though the standard library does not allow to achieve what I wanted from the CPU, and it's a pity.

[mikke89]

Great work, thanks again! Appreciate all the effort that went into this.

I'm merging it into the vulkan branch to polish it up a bit before eventually merging it to master.