[HN Gopher] Dynamic Register Allocation on AMD's RDNA 4 GPU Arch...
       ___________________________________________________________________
        
       Dynamic Register Allocation on AMD's RDNA 4 GPU Architecture
        
       Author : ingve
       Score  : 69 points
       Date   : 2025-04-05 17:51 UTC (5 hours ago)
        
 (HTM) web link (chipsandcheese.com)
 (TXT) w3m dump (chipsandcheese.com)
        
       | JonChesterfield wrote:
       | That's a really good trick. New to me. Anyone know a reasonable
       | way to do the query equivalent? Not allocate more, ask how many
       | are currently available.
        
         | dragontamer wrote:
         | Why bother?
         | 
         | If the next assembly line says to use register#200 (but you
         | failed because you only have 160 registers), what's the
         | processor supposed to do?
         | 
         | The only hope is to call for more registers and lock until
         | those registers are available. There's no way to progress
         | otherwise.
        
           | im3w1l wrote:
           | Dynamically switch algorithms between one that is faster but
           | has more register pressure and a slower one with less
           | pressure. Lowering numerical precision might be on the table
           | too.
        
             | wtallis wrote:
             | And what, refill the instruction cache in less time than it
             | takes to wait for more registers to become available?
        
           | JonChesterfield wrote:
           | Knowing how many registers are allocated is roughly how many
           | are live, which is how many to write to the stack during a
           | coroutine switch.
           | 
           | I'm having trouble with the tradeoff between compiler
           | complexity and perceived value of userspace scheduling on
           | gpus so a means of moving work from compiler into runtime
           | helps lower the barrier to landing the implementation.
           | 
           | Oh, or with the work hat on, function pointers are a nuisance
           | with kernel allocated resources, and a jump table keyed off
           | the result of a register file size query would be a partial
           | solution to that.
        
         | djmips wrote:
         | On AMD ,not available to users yet AFAIK. Only available to the
         | driver and currently targeted at ray tracing?
         | 
         | On Nvidia you have to be writing in the PTX language to have
         | access to something similar.
        
         | Someone wrote:
         | 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)
        
         | dagmx wrote:
         | Given the speed of occupancy changes, you'd almost always fall
         | afoul of TOCTOU on this.
        
       | monocasa wrote:
       | Huh, I would have expected the request for additional registers
       | to be linked into the resource request scoreboarding you see for
       | texture accesses, rt hardware requests, etc. Busy waiting on
       | condition code seems non optimal, and opening the window for
       | cases where one or all shader programs on core can no longer make
       | progress.
        
       ___________________________________________________________________
       (page generated 2025-04-05 23:00 UTC)