Changing group during rendering

Deadline
1

Hello !

I’ve noticed something, and just wanted to ask for confirmation or if it is a wrong behavior.

If a worker start a job with ‘none’ group, after N frames finished, we change the group.
Why if the worker don’t have this group, it still continu to render on this job.

It looks like the worker is allowed to render this job at first frame and then it is never evaluate again, even after changing the group job.

For exemple :

  • launching a job to group none
  • workerB is starting rendering
  • after first frame finished, we change the group to A
  • all workers in group A are allowed to render this job
  • workerB still continue rendering on this job, even if it is not in group A

Thanks !
-p-

2

Have you tried using the “Find Render Candidates” window to see if it may be included in some variation?

3

Groups aren’t intended to be changed while a render is happening, so the check only occurs when the Worker first picks up the job.

You might want to use a machine list instead of groups if you’re looking to lock a job’s render candidates to whatever machines initially picked up the work.

4

Hmmm, I’m probably in a similar boat as we’re changing groups and pools with wild abandon on our new network. I get that a worker wouldn’t suddenly toss a frame it’s in the middle of if it’s no longer in the group. But if I alter the job’s group to a different set of machines, it seems like only the new group’s worth of machines/workers should now pick up the job. Does each worker identify a potential job when the job enters the queue? Shouldn’t it revisit the constraints prior to launching on a frame?

1 Like
5

@RicardoMusch yes that’s what’s un-natural : my render candidate list is OK (aka without workerB) but workerB is still rendering on the job.

@Justin_B I could use machine list, but this is not dynamic : if i add or remove a machine in the groupB, i need to change my script…

I’d prefer a re-evaluation of the candidate list with group on each frame as @antoinedurr is mentioning it if possible

1 Like
6

Yeah I would +1 this, I’ve seen behaviour like this too and it seems silly to not eval on each task start.

1 Like
7

Right, I understand it makes sense for the Worker to re-check candidacy for each task. I don’t know the reasoning so I can’t expand on that.

@pingus43 Could you elaborate on the workflow you’re trying to accomplish? Since we’re not going to be able to change when group checks occur I’d like to at least help you get working as-is.

8

What i was trying to achieve :

groupA : machines with 64Go RAM
groupB : machines with 128Go RAM

  • sending jobs on group none
  • all my workers goes rendering
  • on event : on slave rendering i’m checking RAM consumption
  • if RAM > 64 then i apply groupB on job, so only high machine can render this one
  • if a groupA machine start rendering on the job, it won’t leave this job after group changed

As workaround, i’ve inverted my workflow :

  • all my jobs are launch on group B
  • checking the RAM on slave rendering
  • if a job is <64Go, then i remove the group
  • so groupB worker can start the job

But in this configuration, my groupB worker may stay in Idle, as i would have prefered they start a job and take a risk they failed it because not enough ram.

As i said, i’ve find my workarond for my specific case.
I just find it unnatural that the group (or candidacy) is not check on each frame

1 Like