Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Descriptor Pool maxSets is troublesome

  1. #11
    Quote Originally Posted by GameCodingNinja View Post
    Question... say I have 3 different pipelines and a handful of descriptor sets, ubo's and vertex buffer for each of the pipelines, can this all be recorded in the same command buffer?
    Um... yes. Why would you think you wouldn't be able to?

  2. #12
    Because vkCmdBindPipeline, vkCmdBindVertexBuffers, vkCmdBindIndexBuffer, vkCmdBindDescriptorSets use the term "Bind". To me, binding something means to make it permanent and can't be changed. It sets the stage for everything else that comes next. Other command buffer calls use the term "Set" which doesn't suggest lasting change. In OpenGL you bound your shaders, texturtes and VBO's which effected everything from that point. Using the term "Bind" gives the wrong impression as to what these calls do and how the command buffer works.

  3. #13
    Quote Originally Posted by GameCodingNinja View Post
    Because vkCmdBindPipeline, vkCmdBindVertexBuffers, vkCmdBindIndexBuffer, vkCmdBindDescriptorSets use the term "Bind". To me, binding something means to make it permanent and can't be changed. It sets the stage for everything else that comes next. Other command buffer calls use the term "Set" which doesn't suggest lasting change. In OpenGL you bound your shaders, texturtes and VBO's which effected everything from that point. Using the term "Bind" gives the wrong impression as to what these calls do and how the command buffer works.
    And now I'm even more confused.

    In OpenGL, binding is not permanent. Yes, binding affects what follows, but if you want to render later with a different texture, you don't tear down the whole OpenGL context and create a new one. You just bind a new texture in the same place as the old one and subsequent rendering commands use the new texture.

    Binding in Vulkan works exactly like binding in OpenGL; it affects what follows (in that command buffer), but you can always bind something else.

    "Set" is used when you're setting a value or (small) set of values. "Bind" is used when you're binding an object. They both otherwise work identically; setting data that has already been set overrides that data, and binding objects to a location that they've already been bound to overrides the previous binding.

  4. #14
    If you've ever been in a nerd fight with another engineer, you have no doubt discovered that the meaning of words can be slightly different based on unique experiences and perceptions.

    Before I continue on to my next question, I just want to say how much I appreciate you help in all this. I've been converting my OpenGL game engine over to Vulkan. The tutorial I've been working through has made my current understanding of Vulkan possible, allowing me to get as far as I have with my conversion. The tutorial didn't got into much detail as to fully explain the capabilities of the command buffer and the many way it can be used.

    In a real world scenario of rendering game graphics, render objects come in and out of existence constantly. I see two options that have their pros and cons. What are your thoughts on this?

    1) Render all objects in the same command buffer.
    a) Pro: Only one command buffer is needed
    d) Con: The same command buffer needs to be recorded every frame to allow for object it come in and out of existence.

    2) Each object get's it's own command buffer
    a) Pro: The command buffer is recorded only once and submitted to the queue when the object is active
    b) Con: A lot of command buffers are allocated

  5. #15
    I see two options that have their pros and cons. What are your thoughts on this?
    Neither. You should have one command buffer per-task, per-thread.

    The whole point of the command buffer paradigm is to be able to thread your rendering operation. To generate rendering commands on multiple threads at the same time. If you want to take maximum advantage of this, then you need to have at least one command buffer per-thread.

    But at the same time, threading a renderer can be somewhat difficult. Consider shadow mapping. You need to walk your object hierarchy to find out which objects are "visible" from the light. But you also need to do that to determine which objects are visible for the main rendering. And the two lists of objects won't be the same, even though they're starting from the same source set of objects. And the commands you need for shadow map rendering are not the commands you need for regular rendering.

    For best efficiency (probably), you will want to only walk the object hierarchy once. So on the thread(s) that do this, they should be generating two command buffers. One for the shadow map rendering and one for the main rendering. For each object, they issue commands for both CBs, as needed.

    You would eventually send those CBs to the queue submissions thread, which will know about them and do something useful with them.

    Vulkan works best when your rendering system has a well-defined structure to it. That is, you build "boxes" that you can pour content into. You have a "box" for objects that cast shadows, a "box" for regular objects, a "box" for particles, a "box" for post-processing effects, and so on. This way, you can tailor your threading and CB-building system for the needs of your renderer.

    However, if you're just starting out, that's all extremely complicated. I would instead focus on just using a single command buffer. It'll be easier to go from that to multiple, threaded CBs than it will if you start from having one CB per object.

  6. #16
    Neither. You should have one command buffer per-task, per-thread.
    I have read that you need to create the command pool per thread for the command buffers needed within that thread. Is this true?

    ...then you need to have at least one command buffer per-thread.
    My engine asset creation and destruction is organized by group. Each asset can then be used to create any number of sprites. Each group could have it's own command buffer for it's own thread. You still have to record the command buffer every frame because you don't know which sprite will be visible at any given moment but at least it can be broken up by thread.

    One last question. I'm assuming I can load a new group of assets while rendering a completely different group.

  7. #17
    Quote Originally Posted by GameCodingNinja View Post
    I have read that you need to create the command pool per thread for the command buffers needed within that thread. Is this true?
    No. But yes.

    The technical answer is that access to command pools, and the command buffers generated by them, require "external synchronization". That is, if you allocate a CB from a particular pool, you cannot call any function that manipulates the CB unless you have ensured that no other thread is simultaneously manipulating any command buffer that was allocated from the same pool.

    Now, you could ensure this by creating a mutex for each CB and locking it around when you're adding commands to a buffer and so forth. But this would be terrible for performance.

    The consequence of this is that the most reasonable way to use command pools and the buffers they create is to keep them in the same thread. With the exception of sending them off to a dedicated queue submission thread, but that's a single mutex operation you do on a thread when that thread has done all of its rendering, rather than something you're doing all the time.

  8. #18
    That is, if you allocate a CB from a particular pool, you cannot call any function that manipulates the CB unless you have ensured that no other thread is simultaneously manipulating any command buffer that was allocated from the same pool.
    That makes sense. I appreciate all your help! As I was looking up an example of push constants, I just so happen to discover a feature called "push descriptors". Looks interesting...

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean