Rust-GPU / Rust-GPU/rust-gpu

non-literal workgroup size

Aperta
#299 8 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

enhancement
Lingua principale
Rust
Stelle
3.4k
Fork
126
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

Original discussion in https://github.com/Rust-GPU/rust-gpu/pull/298

Currently, workgroup size must be a number literal and does not accept const expr. So to have a const if your workgroup size, you must copy-paste the literal in two / three locations:

pub const LIGHTING_WG_SIZE: u32 = 64;

const_assert_eq!(LIGHTING_WG_SIZE, 64);
#[bindless(compute(threads(64)))]
pub fn lighting_cs(...) { ... }

I'd much rather have the proc macro accept a const expr instead of a literal, so we can do this:

pub const LIGHTING_WG_SIZE: u32 = 64;

#[bindless(compute(threads(LIGHTING_WG_SIZE)))]
pub fn lighting_cs(...) { ... }
Alternative: WorkgroupSize builtin

The WorkgroupSize builtin as in https://github.com/Rust-GPU/rust-gpu/pull/298 is not sufficient for these use-cases:

  1. Accessing the workgroup size from the CPU code to compute the workgroup dimensions:
let groups = [
	(image_size.x + LIGHTING_WG_SIZE - 1) / LIGHTING_WG_SIZE,
	image_size.y,
	1,
];
  1. Declare shared memory as a multiple of the workgroup size:
pub const DIRECTIONAL_SHADOWS_WG_SIZE: u32 = 64;
const SHARED_SIZE: usize = DIRECTIONAL_SHADOWS_WG_SIZE as usize * 2;

const_assert_eq!(DIRECTIONAL_SHADOWS_WG_SIZE, 64);
#[bindless(compute(threads(64)))]
pub fn directional_shadows(
    #[spirv(workgroup)] shared: &[f32; SHARED_SIZE],
) { ... }
Potential Implementation Path

I wonder if we actually need to parse out the actual value within that macro....

Currently we're emitting this, for which we clearly need to parse the literals:

     OpEntryPoint GLCompute %3 "lighting_cs" %bla %bla2 %bla3
     OpExecutionMode %3 LocalSize 64 1 1
%3 = OpFunction %void None %443

But with Vulkan1.2 we get the new fancy LocalSizeId instead of LocalSize, so we can do this:

%4 = OpTypeInt 32 0
     OpDecorate %5 SpecId 123
%5 = OpSpecConstant %4 64
%6 = OpConstant %4 1
     OpEntryPoint GLCompute %3 "lighting_cs" %bla %bla2 %bla3
     OpExecutionMode %3 LocalSizeId %5 %6 %6
%3 = OpFunction %void None %443

Note how at the point we're writing the OpExecutionMode we don't actually write any literaly, just references to constants. Why couldn't they be references to actual constants in rust code? And if we have number literals, we can still parse and emit them as constants. It would also open up a path towards workgroup size being a spec constant, see %5.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia tracciando la gestione da parte del proc macro di #[bindless(compute(threads(...)))] e il modo in cui attualmente emette OpExecutionMode LocalSize. Leggi la discussione originale nella pull request 298, quindi confronta il percorso esistente per i literal con il LocalSizeId proposto e i riferimenti alle costanti. Il lavoro è completato quando le espressioni const vengono accettate per le dimensioni dei workgroup, mantenendo il supporto per i literal.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
rust
Ambito
compilers
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.