Results 1 to 3 of 3

Thread: main and render thread

  1. #1
    Member
    Join Date
    Aug 2016
    Location
    Germany
    Posts
    35

    main and render thread

    Hello.

    I'm on the way extracting all content used for rendering into a new thread created when the programm is gonna start.

    I'm looking for some advices in this topic. The problem is that I'm not sure what should stay in the main thread and what shouldn't.

    The first thing I like to move is all code that is responsible for QueuePresent.

    So, should the code that recreates my commandBuffers also go into the renderThread?

    The problem here is that a commandPool is not threadsave. Therefore I think recreation should stay on
    the main thread, right?

    Another question is: Where does rendering exactly happen? As I know QueuePresent is the responsible call
    to signal to render the next image. The commandBuffers are just structures that describe what to do when calling QueuePresent.
    So commandBuffer recreation is not a heay task, right? The heavy task is QueuePresent that should go into a new render thread.

    Am I right? I really hope to get some good answers thanks.

    .black

  2. #2
    Quote Originally Posted by .black View Post
    Hello.

    I'm on the way extracting all content used for rendering into a new thread created when the programm is gonna start.

    I'm looking for some advices in this topic. The problem is that I'm not sure what should stay in the main thread and what shouldn't.

    The first thing I like to move is all code that is responsible for QueuePresent.

    So, should the code that recreates my commandBuffers also go into the renderThread?

    The problem here is that a commandPool is not threadsave. Therefore I think recreation should stay on
    the main thread, right?

    Another question is: Where does rendering exactly happen? As I know QueuePresent is the responsible call
    to signal to render the next image. The commandBuffers are just structures that describe what to do when calling QueuePresent.
    So commandBuffer recreation is not a heay task, right? The heavy task is QueuePresent that should go into a new render thread.

    Am I right? I really hope to get some good answers thanks.

    .black
    It is advised that each thread has its own command pools so that way you don't have to synchronize them. the drawback is that the command buffers can't be shared either. There are no rules of thumb in this matter. Each application has its own set of features, so investigate to see what fits better your needs

    The rendering starts as soon as the semaphore provided in the command buffer submit, if any, is signaled, if there is no semaphore, it starts immediately. And you can tell it has safely ended as soon as the semaphore provided in the queue submission is signaled. You're misunderstanding what the swapchain does with the syncrhronization process. Think that the swapchain is just an extension provided for convenience, you can render without a swapchain perfectly. The swapchain just ensures that its own structures are safe when you request a new image and when you present it, and does all the memory transfer for you to show the image in a window. Just that. It provides the necesary syncrhonization facilities so you don't get it its way, and it doesn't get in yours.

    Command Buffers are within the command pools, so recreating them is as simple, or complex, as releasing memory and acquiring them anew when they're not in use. You can use, perhaps, two (or more) buffers instead of one, so you can process one while other is being recorded and the third is waiting for its proper release.

  3. #3
    Member
    Join Date
    Aug 2016
    Location
    Germany
    Posts
    35
    Quote Originally Posted by SantiagoAlberto View Post
    It is advised that each thread has its own command pools so that way you don't have to synchronize them. the drawback is that the command buffers can't be shared either. There are no rules of thumb in this matter. Each application has its own set of features, so investigate to see what fits better your needs

    The rendering starts as soon as the semaphore provided in the command buffer submit, if any, is signaled, if there is no semaphore, it starts immediately. And you can tell it has safely ended as soon as the semaphore provided in the queue submission is signaled. You're misunderstanding what the swapchain does with the syncrhronization process. Think that the swapchain is just an extension provided for convenience, you can render without a swapchain perfectly. The swapchain just ensures that its own structures are safe when you request a new image and when you present it, and does all the memory transfer for you to show the image in a window. Just that. It provides the necesary syncrhonization facilities so you don't get it its way, and it doesn't get in yours.

    Command Buffers are within the command pools, so recreating them is as simple, or complex, as releasing memory and acquiring them anew when they're not in use. You can use, perhaps, two (or more) buffers instead of one, so you can process one while other is being recorded and the third is waiting for its proper release.
    Your answer really helps me out. That means that if QueueSubmit gets executed the semaphore will be signaled if rendering is done, right?. After that is done QueuePresent just prints out the picture.

Tags for this Thread

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