Rust-GPU / Rust-GPU/rust-gpu

non-literal workgroup size

オープン
#299 コメント 8 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement
主要言語
Rust
スター
3.4k
フォーク
126
PR マージ指標
30日以内にマージされた PR はありません

説明

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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、proc macro による #[bindless(compute(threads(...)))] の処理と、現在どのように OpExecutionMode LocalSize を出力しているかを追跡します。pull request 298 の元の議論を読み、既存のリテラルの経路を、提案されている LocalSizeId および定数参照と比較します。workgroup サイズに const 式が受け入れられ、リテラルのサポートが維持されれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
rust
領域
compilers
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。