Comments (5)
Have you tried it with out rust-gpu? Like using GLSL directly in WGPU, or using SPIR-V generated by GLSLang or HLSL in WGPU? I'm not sure how this isolates to rust-gpu otherwise, even if it is the problem.
from rust-gpu.
I am using rust-gpu
so I can use my Rust knowledge for graphics programming. I am not a graphics programmer who wants to use Rust. It is a good suggestion though, I'll poke around and see if I can eliminate some variables. Thank you!
from rust-gpu.
Adding #[inline(always)]
to the functions in the shader speeds it up a bit. It is still slow, but reasonably faster than before.
from rust-gpu.
First, I finally had a proper look at your code, I think you may have a bunch of implicit slow behavior going on. Primitive choice matters a lot GPU because of the massive difference in performance, particularly between i32, f32,and f64 (yes, all three have completely different performance characteristics that vary wildly platform to platform, Ada as 1/2 the i32 as f32, and either 1/32 or 1/64 I believe f64 as f32). I think you might have a bunch of f64 math by accident here, but it's hard to tell, since rust doesn't really give a let x= 1.0
literal instantiation a type until after it's been used, and I'm not sure how Rust-GPU handles this.
For example, this:
Vec3::new(0.2, 0.7, 0.9)
Seems fine, but this:
let mut t = 0.0;
might not be fine and could result in t
being a double (at least for Rust GPUs code-gen), which on Nvidia at least, would result in 1/32 the performance for basic float math compared to float 32 depending on if you used a consumer graphics GPU or a server grade GPU. I would probably consider this a bug in Rust GPU if it didn't handle this properly.
Next, Have you run the spir-v output through SPIR-V Opt? I don't think Rust GPU does any serious optimization passes though I could be wrong, and by default sharderc and glslang actually do run their generated spir-v through SPIRV opt if I remember correctly. OpenGL works differently if you don't use the SPIR-V extensions, (ie like WebGL) so it's basically implicitly doing a bunch of optimization passes behind the scenes at the driver level, before it's even turned into gpu IR (or, if you're on safari, who knows what's happening).
One way or another, you're going to have to take a look at rust-gpu's generated spirv for the same code as GLSLang/shaderc's if those actually produce faster SPIR-V, and to determine that, you need to isolate, so use spirv from those programs and run it through your current codebase, and benchmark. Luckily that shader doesn't look too complicated, so it should be pretty straight forward to also port it to standalone vulkan GLSL, likely easier than rust-gpu, but that's something you need to do.
-
So first, test if it's just because it hasn't been run through spir-v opt. If it is, it's not a problem with rust-gpu. There's no point in duplicating Khronos Groups effort here.
-
If it's just as slow with shaderc/glslang run through spir-v opt, it's not the Rust GPU shader, it's moltenvk or wgpu or what ever you're using to actually run these shaders on Mac. Note massive perf differences between these tools and WebGL may be expected, because the projects aren't related at all, if you're running shadertoy on safari, you're using Apple's implementation of WebGL, which may go directly to Metal.
-
If it's faster with shaderc/glslang, then you'll need to look at the decompiled SPIR-V and compare the output between the GLSL shader you made, and the rust-gpu one, again, the shader looks simple enough that you should easily be able to determine what functions are what. Make sure you output debug symbols into your SPIR-V.
-
From there you can start to find where this program is going wrong. I would recommend you exactly match the glsl, not just kind of match it, for example , while the code in the GLSL just uses a float for time, you seem to have created a new type struct for it
#[derive(Clone, Copy)]
struct Time(f32);
-
Who knows what's going on there with code gen, for all I know, Rust GPU treats that as a struct with a single member, then implements copy and clone actual SPIRV-V functions for that type, generating a bunch of actual function calls and access chain instructions which wouldn't normally be needed since it's just a float. That might be a bug, but again, sounds like the kind of thing SPIR-V opt or your actual SPIR-V compiler from your driver would take care of anyway? You also wouldn't be able to inline these functions manually using this derive attribute IIUC..
-
Once you isolate the problem, you should be able to make a new issue that better specifies an actionable specific cause of the problem.
from rust-gpu.
Awesome, thanks for the pointers! I Hope to look into this more after the holidays.
from rust-gpu.
Related Issues (20)
- Unable to build rustc_codegen_spirv with nightly 2023-09-30 HOT 5
- Improve documentation to include visual of what example app should look like? HOT 2
- Conditionals and code generation performance HOT 3
- Cargo component not available with nightly 2023-05-27 which is publicised on crates.io
- adding spirv-std anywhere in the worskspace, slows down the CPU code due to libm feature
- Compile with Proc Macro HOT 2
- Large array variable initialization (`let arr = [0; 32 * 1024];`) compiles very slowly. HOT 2
- Inliner->`mem2reg` can quadratically amplify already-exponential inlining (turning seconds into minutes).
- Consider build CLI (e.g. `cargo gpu`) mapping `spirv-std` deps to toolchain & backend versions. HOT 4
- Make error messages more human HOT 1
- Warn (or error) on a non-pub entrypoint HOT 1
- spirv-tools: Assertion `env != SPV_ENV_WEBGPU_0' failed.(my bug report)
- Allow to compile rust-builder as a static c library with the builder calls exported
- Allow for dynamic indexing of texture arrays. HOT 3
- Operator Overlaoding support HOT 2
- Compiling uom crashes the compiler
- spirv_builder sometimes cannot find symbols
- discord link expired
- Redirect to active community-maintained fork
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-gpu.