3 ms·
I don’t know whether it’s reasonable, but > Allocation requests don’t always succeed. s_alloc_vgpr sets the Scalar Condition Code (SCC) to indicate success, or
by Someone 2y ago
I don’t know whether it’s reasonable, but
> Allocation requests don’t always succeed. s_alloc_vgpr sets the Scalar Condition Code (SCC) to indicate success, or clears it on failure.
So, you can do a binary search:
- set result to zero.
- try to allocate 512. If that succeeds, add 512 to result
- try to allocate 256. If that succeeds, add 256 to result
- try to allocate 128. If that succeeds, add 128 to result
...
- try to allocate 1. If that succeeds, add 1 to result (you’ll want to stop at the granularity at which registers are allocated)
- free ’result’ registers
(This isn’t race-free)
- Tuna-Fish 2y agoNote that: 1. Registers are not allocated individually, but in clusters of 32, and... 2. The max registers a single thread can access is 8 clusters (256 registers). The minimum is 1 cluster. You don't really need much of a binary search for this.
- dragontamer 2y agoThe issue is there's plan b: spill your data to L1 cache. Whatever plan you have needs to be far faster than L1 cache to even make sense. I can imagine some very heavy register-pressure situations where registers are much better than cache accesses.