Threading errors in Vulkan when using SCHED_RR

Graphics / Linux Linux
1

Any time I try to use the scheduler policy SCHED_RR in a Vulkan SC program (using the Khronos Emulation ICD), I encounter an unexpected issue during initialization.

If I have a validation layer enabled, I get this when calling vkCreateInstance() (I’m using some similar debug code to what’s in the sc cube demo):

"ERROR : GENERAL - Message Id Number: 0 | Message Id Name: Loader Message
loader_validate_layers: Layer 0 does not exist in the list of available layers

Objects - 1
Object[0] - VK_OBJECT_TYPE_INSTANCE, Handle 0x55efb6c07e40"

If I have validation/debug disabled, I get an incorrect number of queues reported for a given queue family (the answer changes for the same device, vs. when I just use the default scheduler!). This causes my application to fail, since it had been configured to use a queue that disappeared.

To produce the issue, all I do is select SCHED_RR as the scheduler policy for my main thread before calling into the VK API (the actual priority doesn’t make any difference, I get the same errors)…also, note that my code does validate return codes, etc. For example:

int err;
const struct sched_param param = {.sched_priority = 10};
err = pthread_setschedparam(pthread_self(), SCHED_RR, &param);

Note that in order to be able to even set the priority like this, your system may need some additional security (capability) configuration:

sudo setcap “cap_sys_nice=+ep” <app_binary_name>

and the following code before attempting to set the scheduler and priority:

int i;
struct rlimit rlim;

rlim.rlim_cur = 99;
rlim.rlim_max = 99;
i = setrlimit(RLIMIT_RTPRIO, &rlim);

i = getrlimit(RLIMIT_RTTIME, &rlim);
rlim.rlim_cur = 100000;
i = setrlimit(RLIMIT_RTTIME, &rlim);

SCHED_RR is very commonly used in embedded, safety-critical applications, as it provides a very well bounded and deterministic means of allocating CPU resources. I can stick to the default system scheduler as a work-around, but it seems this ought to work.

The crashes occur before I even spawn threads when SCHED_RR is used. Simply having it set before any interaction with the Vulkan SC API results in the crash, all while still running single threaded (in the app code…the driver stack does appear to create threads).

The same code using SCHED_OTHER (the default) works, including with multiple threads. I have synch around the queue and presentation code, and if I deliberately break it I get validation errors and eventually crashes.

I have an RTX3070 MaxQ laptop GPU, running Arch Linux. XFCE with compositing disabled, on X11.
6.15.7-arch1-1
lib32-nvidia-utils 575.64.03-1
linux-firmware-nvidia 20250708-1
nvidia-open 575.64.03-4
nvidia-prime 1.0-5
nvidia-settings 575.64-1
nvidia-utils 575.64.03-1
opencl-nvidia 575.64.03-1

2

…crickets….