davisking/dlib

Choose backend (GPU/CPU)

Open

#1,852 opened on Jul 31, 2019

View on GitHub
 (12 comments) (1 reaction) (0 assignees)C++ (12,570 stars) (3,314 forks)batch import
enhancementhelp wanted

Description

So I couldn't find a way to do this in the documentation but I was wondering if there was a way to force dlib to use the CPU if it's built with CUDA enabled? I ask because I'm making a multithreaded application with dlib and only a maximum of 2 threads at a time can use CUDA (because of limitations of the GPU itself). So I'd like to in a thread get dlib to use the GPU in the thread if <2 threads are using the GPU and otherwise fallback to using the CPU.

Also a slightly related question how would dlib cope with a machine with multiple GPUs installed all for compute purposes?

Contributor guide

Tech stack
ccpppython
Domain
machine learningbackend
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Basic understanding of dlibFamiliarity with CUDAMultithreading concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
The issue requests a runtime mechanism to choose between GPU and CPU execution in dlib, especially for multithreaded scenarios where GPU resource is limited. The discussion highlights the need for a thread safe fallback. To address this, one should examine dlib's CUDA integration in the source code (e.g., dlib/dnn/tensor cuda.cpp) and the threading model. Possible approaches include adding a global or thread local flag to disable CUDA or use a GPU lock. The maintainer has not provided specific guidance, so any solution would require careful design to minimize performance impact.