Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

How to run a compute dispatch without blocking rendering

Discussion in 'General Graphics' started by JohnE4D, Oct 5, 2021.

  1. JohnE4D

    JohnE4D

    Joined:
    Jul 1, 2021
    Posts:
    5
    Hi, I have written a compute shader that takes in two meshes, and then calculates the distance to the closest point on the second mesh for every vertex on the first. This is then used to display a "heatmap" in a normal shader to show how close the models are to colliding. The output of the compute shader is a buffer of floats corresponding to the vertices of the first mesh.

    My problem is that the calculation takes too long to be done in a frame, and it blocks the render thread when it runs. I dont mind displaying an outdated result while waiting for a fresh one, but I need the calculation to be non blocking. Is there any way to do this without Async Compute support? (The bool is false on Vulkan and DX12 for a quadro rtx 3000)
     
  2. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,751
    Without async compute the GPU can either be doing graphics or compute, it cannot do both at the same time. Your options are either find out ways to optimize your compute algorithm so it runs faster, or do the work on the CPU instead using separate threads.
     
    JohnE4D likes this.
  3. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    2,240
    Or break your compute dispatch up into chunks so it only computes the heatmap for N vertices per frame. Instead of all of them. Then call it over a few frames until it's done all the vertices.

    (That said - your problem doesn't sound like the kind of thing that should take very long to compute. Are you doing a brute force check of every vert vs. every other vert? If so, consider some kind of spatial partitioning/binning of your geometry to speed up the search, like a voxel grid, for example)
     
    JohnE4D likes this.
  4. JohnE4D

    JohnE4D

    Joined:
    Jul 1, 2021
    Posts:
    5
    Yea, thats looking to be the way to go. Even when broken up with as few as 128 verts per frame, the length of each threads execution (a 300k loop) is way too long. Im looking into a voxel grid binning to solve the issue. Thank you!
     
    richardkettlewell likes this.