Lack of unrolling and very high register usage

未关闭
#462 4 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

@Firestar99 已经在做这个了。

开始于 2025年11月26日。

评估

这个 Issue 还没有评估数据。

描述

enhancement

I have many places in the code that can be condensed to something like this:

const MAX_BUCKET_SIZE: usize = 512;
const WORKGROUP_SIZE: u32 = 256;

unsafe {
    core::hint::assert_unchecked(matches_count <= MAX_BUCKET_SIZE);
}
for index in (local_invocation_id..matches_count as u32).step_by(WORKGROUP_SIZE as usize) {

Can also be rewritten in a way that will probably produce some helpful runtime code in SPIR-V since I suspect the hint will be lost in translation:

const MAX_BUCKET_SIZE: usize = 512;
const WORKGROUP_SIZE: u32 = 256;

for index in (local_invocation_id..matches_count.min(MAX_BUCKET_SIZE) as u32)
    .step_by(WORKGROUP_SIZE as usize)
{

It is not difficult for me to see that there will be at most two loop iterations here per invocation. However, it is not something compiler sees today.

The result is much higher register usage, impacting occupancy in a big way.

Rewriting it to inner function that is called twice with explicit bounds checks fixes register usage (though I hit https://github.com/Rust-GPU/rust-gpu/issues/461 when doing so), but is far from idiomatic Rust and is quite painful to do manually in all such cases.

I wish end-to-end compilation chain was aware of things like this, it is a very important pattern for performance.

In fact loop unrolling is extremely bad right now, even fixed loops with 3-4 iterations and one or several simply ALU instructions in it are not unrolled and balloon register usage.

主要语言
Rust
星标
3.4k
派生
126
PR 合并指标
30 天内没有已合并 PR

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

Rust-GPU/rust-gpu 的其他 Issue

查看 Rust-GPU/rust-gpu 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。