Advertisement Jump to content
  • Advertisement

Laval B

  • Content Count

  • Joined

  • Last visited

Community Reputation

12388 Excellent

About Laval B

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Laval B

    Vulkan and DX12 similarities

    They are similar mostly because they were designed to achieve the same goals : low CPU overhead, parallel command recording and submission and more fine grained control on resources and pretty much everything. They are more similar then the previous generation APIs because they are both a thin abstraction of the device. They do hide the driver API specifics but they do not hide the concepts i.e. the way the device actually works. Since they expose the same GPUs and the same concepts, they just do the same thing. Previous generation APIs were trying to obfuscate the GPUs and driver notions. There are some small differences mostly because Vulkan had to cope with a wider range of devices (mobile devices using tiler GPUs). The most notable of these differences is the notion of a render-pass being decomposed into sub-passes with Vulkan. There was no common document, to my knowledge at least, that both Khronos and Microsoft followed, just the same goals on roughly the same hardware as well as the same demands from the game developers. It is true however that AMD gave the Mantle specification to the Khronos group to speed up the process of Vulkan development (as a spec).
  2. Laval B

    Multithreaded Rendering

    I mean the call to present, the moment when you give your image back to the swap chain.
  3. Laval B

    Multithreaded Rendering

    Just to make sure i understand you correctly, the presentation doesn't occur until all command buffers have been constructed (in parallel) ?
  4. We changed from KDevelop to Visual Studio Code six months ago and i must say i'm rather pleased. It has pretty much all the important features of Visual Studio and it works on multiple platforms. It can also be used for almost all languages provided you install the proper plugins. We have tried Eclipse with CDT a year or so ago, but it was horrible in terms of resources consumption, speed and features. KDevelop is also very good.
  5. Laval B

    Multithreaded Rendering

    That's very nice ! I'll take a look at that presentation. Thank you very much.
  6. Laval B

    Multithreaded Rendering

    This could be a good idea indeed but how would you manage the life cycle of the secondary command buffers ? I was looking at Sascha Willems multi-threading sample which uses secondary command buffers and i think there is a few things i didn't understand well about it.
  7. Laval B


    You cannot change a pipeline state that is not listed in the dynamic states, you need to make another (others) pipeline(s) and bind the appropriate one in your sub-passe. In such a case, your pipeline layout wouldn't change and your binding would be the same. Perhaps your even use the inheritance feature to simplify the creation. Vulkan/DX12 are all about pre-backed state.
  8. Hello everyone. I am currently looking at remaking our rendering back-end from the ground up. The goal is to multi-thread rendering and to move to 2nd generation APIs. So i have been looking at those APIs (mostly Vulkan and somewhat DX12 so far which are quite similar) and i think i have a decent understanding of how they work. Just to give the big picture, the front-end of the rendering system is responsible for implementing the rendering logic of different parts of the scene like terrain (LoD, view-frustum culling) etc and produces rendering commands for the back-end in the form of state objects and resources to bind. These objects are created using builder objects and can be built of multiple threads since they don't contain any GPU objects. When submitted to the back-end, the rendering thread just sets the states and performs the draw calls. This design is very friendly to 2nd generation at a first glance. I did take a look at DOOM3-BFG Vulkan renderer and what they do is to use an array of "frame" objects (one for each image of the swapchain). Each has a command buffer and when drawing commands are submitted, they wait on the fence of the current frame (which most of the time will be finished) and record the command buffers on the presentation thread and they just ping-pong the two command buffers from frame to frame. It's easy but it doesn't leverage the API capabilities. My idea is to use a similar frame mechanism for the back-end while building command buffers on other threads. The builder objects could be used by the front-end (taking care to make the render pass concept first class citizens in the builder API). The builder could just be making Vulkan objects directly and just produce opaque objects that the rendering thread would just have to submit. At this point of my reflection the main issue i'm facing is the management of the command buffers life cycle since they are allocated from command buffer pools. The rendering thread could reset the command buffer (by resetting the pool) and the handing it back to a queue when the front-end could get them but it would require that the pool be submitted with the command buffer and it would also require more synchronisation.
  9. Laval B

    Serialization libraries in C

    You can use text-based file format or binary file format. Text files are handy to work with because they are human readable and you can modify them easily with a text editor while developing and debuging. If your files are very simple, the fprintf/fscanf method mentioned above will probably do just fine. If you need structured data (sections, types and repeating sequences of data) using a format like JSON might just be a good idea. A C library that works well could be There is actually many such libraries available on the web. Kylotan's post has interesting informations about serialization and frameworks. My advice would be to start by using simple methods then go for more sophisticated encoding as needed.     A word of caution on this if i may. Don't forget that the Java virtual machine is big endian so if you decide to go for binary files and, for some reason, some Java application needs to read or write these data files (Android version of the game made in Java for exmaple) byte order will have to be taken care of .
  10.   +1 I totally agree.
  11. Laval B

    Code quality at work

      This is also true for me. Managers have different concerns then most developers, they need respect budget and deadlines. Some are just a bit too shortsighted sometimes. We are spending more time dealing with poorly organized code on a regular basis then it would have taken to just fix some things in the first place. At some point, you accumulate so much problems that it becomes impossible to even do a simple modification and then, you need change big things.
  12. Laval B

    Object lifecycle management

    One last question if i may.   Would it be too much of a restriction to require that updates as well as resource creation/destruction could be done onlt by a single thread at a time ? It wouldn't need to always be the same and the construction of the update liste could itself be done concurrently on multiple threads but it could be submitted only from one thread (at a time). It simplifies many things and allows for uptimisations to have a single producer thread.
  13. Laval B

    Object lifecycle management

      This methods is very intesting because, for one thing, it would allow me to be able to modify/replace the content of a buffer that is currently in use. This is something i wasn't even considering at this point. The nice thing about it is that it isn't really that difficult to implement. The list of things to be deleted is a great idea. I will probably need some sort of reference counting because there may me multiple updates queued that use the same buffer (resources). Just a couple of questions :   1. Just to make sure i follow you, when you say "(where you can give them a buffer with any old contents in it)", do you mean recycling an old buffer (memory area) ? 2. The list of buffers to be deallocated would be processed by the mixer thread when it's done with the current update ?     Thank you very much for the idea.
  14. Laval B

    Object lifecycle management

      You are right. The only moment i can think of where there can be more important allocation is when a level is unloaded to load another one. Using pools for source and buffer objects would also make allocation/deallocation time deterministic and short. Even the buffer's data could be from a linear allocator i guess.   Thx for the thoughts.
  15. Laval B

    Object lifecycle management

      Yes, reference counting is the solution i was trying to avoid but i guess there isn't must choice since buffers are shared. I still don't like the idea that the mixer thread has to do memory management.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!