Hi
I've been rendering for quite a while fetching a redshift render node in my pdg networks, but only recently realized that render time seems to double, compared to the standard redshift "render to disk".
Do you know why this is happening?

Is it running multiple renders at the same time?

No it's not.
I have "All frames in one batch" active, but it does the same if i have render a one frame sequence

A few things to keep in mind:

• PDG work items cook out of process -- a ROP Fetch task will run a Hython process that loads the scene file and cooks the target ROP node. If you're not caching out your geometry to disk, then the render will have to trigger a cook of the geometry before rendering. In other words, ideally your scene file should be set up in such a way that the render tasks can just load the cached geometry from disk instead of having to recreate it.
  
• Check your scheduler settings to make sure you're not limiting the number of threads that jobs can use.
  
• Compare the performance with rendering your ROP using hbatch. This is a more accurate comparison than cooking in a live session, since the scene is loaded and cooked from scratch. For example, something like:
  
  

  hbatch myscene.hip
  >>> render /path/to/redshift_rop

  
  
• The ROP Fetch TOP has an option to enable Performance Monitor logging for the work items. Comparing the perf mon output between a PDG task and a regular render in a graphical session may help to determine where the extra time is being spent
  

If those suggestions don't help your track down the issue, then please log a bug with a .hip file that reproduces the issue, the logs for your work item(s), and the specific version of Houdini and Redshift you're using.

Awesome, thanks! Will try that.

I have to add that all my geo is cached and I am monitoring video card usage also, so I know when the render actually starts.
It's almost as if the render setup was using different settings.

Finally had some time to test this out.
I didn't know it was also GPU related, but as you said, increasing the amount of total slots in the scheduler available solved this problem.