AcademySoftwareFoundation / AcademySoftwareFoundation/OpenCue
Improvements/ideas for GPU support
- Dominant language
- Python
- Stars
- 957
- Forks
- 259
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 16
Description
I'm not 100% how to word this, but here it goes.
Looking at #924 I have these ideas.
GPU hosts don't pick up non-GPU frames: If a host has CPU and GPU it should be able to run CPU and GPU frames regardless of type, with possible preference to GPU. Additionally some frame types may be able to utilize CPUs and GPUs,
GPU jobs are not like CPU jobs: OS will migrate CPU jobs to idle CPUs as needed. GPU jobs are usually assigned to 1 or more GPUs at startup and they continue to run on only those GPS until finished. I propose something similar to how a frame number passed to the command for GPU assignment. This would be managed by rqd. rqd only needs to tell cuebot number of free GPUs.
Are these bad ideas? Are there better ideas?
Contributor guide
Research direction
Start by reading issue #924 and tracing the existing GPU-related behavior between rqd and cuebot. The issue proposes changes to frame eligibility, GPU assignment, and reporting free GPUs, but it does not identify files, tests, or a settled design. A concrete implementation plan and acceptance criteria would be needed before work is ready.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100