It is quite often the case that, when doing a single-frame rendering, a single tile (or a very small number of tiles) gets "stuck", eventually times out and completely destroys performance.
Endgame optimization tries to remedy this by parallelizing work on the remaining N tiles (e.g., N = 1 or 2) and accepting the first incoming result.
This would have to be realized in bitwrk-client, which currently has no notion of single work units belonging to a larger job (group of work units). This understanding would have to come from e.g. the blender add-on.
It is quite often the case that, when doing a single-frame rendering, a single tile (or a very small number of tiles) gets "stuck", eventually times out and completely destroys performance.
Endgame optimization tries to remedy this by parallelizing work on the remaining N tiles (e.g., N = 1 or 2) and accepting the first incoming result.
This would have to be realized in bitwrk-client, which currently has no notion of single work units belonging to a larger job (group of work units). This understanding would have to come from e.g. the blender add-on.