AMD Working To Allow Linux To Handle Up To 128 DRM Devices Per System

[phoronix]

Phoronix: AMD Working To Allow Linux To Handle Up To 128 DRM Devices Per System

AMD Linux engineers are working on extending the Direct Rendering Manager (DRM) subsystem used by their GPUs/accelerators to allow up to 128 DRM devices per system...

https://www.phoronix.com/news/Linux-128-DRM-Devices

[nerdopolis]

Multi-seat users rejoice? Although it's probably not that viable for multiseat, as the last well-supported USB card is DisplayLink 2 devices AFAIK

[Peter Fodrek]

What about using each CU as DRM device and switch on and off CU/DRM device on demand and creating set of DRM devices (composed DRM device) to render certain monitor of window on the fly?

This will help GPU chiplet arachitecture to be properly programmed

[dimko]

Sounds like smth useful for those AI people.

[schmidtbag]

I also feel this might relate to chiplets, where perhaps each die is treated as a separate DRM, though at that point it gets me to wonder how that's different from Crossfire.

[ddriver]

What about using each CU as DRM device

The who gpu pipeline will perform abysmally if you try to grain it this way. You need to use cus in parallel, otherwise it defeats the purpose.

It would be equivalent to multithreading on a pixel level, that is using a dedicated thread for every next pixel. The overhead will be so huge the single threaded solution will run circles around the MT.

All those things are abstracted away in compute kernels, the gpu will analyze its runtime performance and adjust cu allocation per task as needed so it balances between over and under provisioning. You never need to touch that stuff or rely to be consistent, it is dynamic and automatic.

[OneTimeShot]

I know that it's a security risk to let a system register an infinite number of things, but how did they come up with the number 128? Is there a 7-bit number in there somewhere?

Why not 256 or 1024?

[ddriver]

7 bits of data for a range of 0-127 and 1 bit dedicated for some flag. Back in the olden days everything was 127 cuz the last but was reserved for parity integrity checks.


1024 would be extremely odd, as it is 10 bits. We don't like wasting space in kernel programming, so mostly power of two sizes are used not only for primitive sizes in bytes, but also for bit field sizes. 1, 2 and 4 are mostly used because they fit within 32 and 64 bit values without padding.

[brucethemoose]

Possibly relevant paper:

https://arxiv.org/pdf/2307.02666.pdf

In a nutshell, Microsoft hypothesized that the most cost efficient AI inference machine is a huge PCB of modest, monolithic chips with no external memory and tons of SRAM. This avoids the costs of huge dies, tricky packaging, slow external memory and such. Queues of requests can be split and pipelined across the chips.

...It doesn't sound like something they need AMD GPUs for, but what do I know?

[Shtirlic]

I know that it's a security risk to let a system register an infinite number of things, but how did they come up with the number 128? Is there a 7-bit number in there somewhere?

Why not 256 or 1024?

128 is enough for everyone's need (c)