profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/khyperia/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

gfx-rs/rspirv 345

Rust implementation of SPIR-V module processing functionalities

khyperia/CudaSharp 156

A library to make C# run on CUDA-enabled GPUs

khyperia/Clam 39

A high-quality fractal viewer

khyperia/scopie 32

Astrophotography control software for khyperia's setup

khyperia/Bifrost 3

DCPU mod for KSP

khyperia/khyperia.com 2

Code for khyperia.com - ridiculously simple, because the web is hard and I am not smart

khyperia/pseudogrey 2

Example of pseudogrey colors

khyperia/Astropress 1

An astrophotography stacking program

issue openedEmbarkStudios/rust-gpu

`core::Option::<u32>::unwrap_or` generates code which requires the Int8 capability

Expected Behaviour

The Int8 capability not to be needed

Example & Steps To Reproduce

I tried to build our compute example: https://github.com/EmbarkStudios/rust-gpu/blob/8c05636f5328e1ea5c88194e64c8e657ce572524/examples/shaders/compute-shader/src/lib.rs#L1-L48 without the Int8 Capability: https://github.com/EmbarkStudios/rust-gpu/blob/8c05636f5328e1ea5c88194e64c8e657ce572524/examples/runners/wgpu/src/lib.rs#L107

And got the following error:

error: u8 without OpCapability Int8
    --> C:\Programs\Rustup\toolchains\nightly-2021-06-09-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ptr\mod.rs:1136:1
     |
1136 | pub(crate) unsafe fn align_offset<T: Sized>(p: *const T, a: usize) -> usize {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: Stack:
             core::option::Option<T>::unwrap_or
             compute_shader::main_cs
             Unnamed function ID %27

(that span also seems wrong?)

The code of unwrap_or is

    #[inline]
    #[stable(feature = "rust1", since = "1.0.0")]
    pub fn unwrap_or(self, default: T) -> T {
        match self {
            Some(x) => x,
            None => default,
        }
    }

which obviously does not use the align_offset function.

A minimised reproduction is:

#![cfg_attr(
    target_arch = "spirv",
    feature(register_attr),
    register_attr(spirv),
    no_std
)]
// HACK(eddyb) can't easily see warnings otherwise from `spirv-builder` builds.
#![deny(warnings)]

extern crate spirv_std;

#[cfg(not(target_arch = "spirv"))]
use spirv_std::macros::spirv;

// Adapted from the wgpu hello-compute example

// LocalSize/numthreads of (x = 64, y = 1, z = 1)
#[spirv(compute(threads(64)))]
pub fn main_cs() {
    None.unwrap_or(0);
}

which produces this spir-v file. module.minimal.spv.zip

Note that 'manually' monomorphising the function makes it compile as expected. This is blocking us from using the naga validation for shaders which use this function, although even with a test fix on the naga side, it still thinks there are problems (with the collatz example specifically).

Note: I've given the dissambly (below) a read through, and the actual code produced is extremely weird. The actual things which need the capability are basically converting a constant bool to a u8, then back into a bool.

<details> <summary>Disassembly hidden</summary> ; SPIR-V ; Version: 1.3 ; Generator: Google rspirv; 0 ; Bound: 42 ; Schema: 0 OpCapability Int8 OpCapability Shader OpCapability VulkanMemoryModel OpExtension "SPV_KHR_vulkan_memory_model" OpMemoryModel Logical Vulkan OpEntryPoint GLCompute %1 "main_cs" OpExecutionMode %1 LocalSize 64 1 1 %2 = OpString "examples\shaders\compute-shader\src\lib.rs" %3 = OpString "C:\Programs\Rustup\toolchains\nightly-2021-06-09-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\option.rs" OpName %compute_shader__main_cs "compute_shader::main_cs" OpName %core__option__Option_i32_ "core::option::Option<i32>" OpMemberDecorate %core__option__Option_i32_ 0 Offset 0 OpMemberDecorate %core__option__Option_i32_ 1 Offset 4 %int = OpTypeInt 32 1 %uint = OpTypeInt 32 0 %void = OpTypeVoid %9 = OpTypeFunction %void %core__option__Option_i32_ = OpTypeStruct %uint %int %uint_0 = OpConstant %uint 0 %uchar = OpTypeInt 8 0 %bool = OpTypeBool %false = OpConstantFalse %bool %uchar_1 = OpConstant %uchar 1 %uchar_0 = OpConstant %uchar 0 %true = OpConstantTrue %bool %17 = OpUndef %core__option__Option_i32_ %compute_shader__main_cs = OpFunction %void None %9 %18 = OpLabel OpLine %2 20 4 %19 = OpCompositeInsert %core__option__Option_i32_ %uint_0 %17 0 OpLine %2 20 4 %20 = OpCompositeExtract %uint %19 0 %21 = OpCompositeExtract %int %19 1 %22 = OpCompositeInsert %core__option__Option_i32_ %20 %17 0 %23 = OpCompositeConstruct %core__option__Option_i32_ %20 %21 OpLine %3 410 12 %24 = OpSelect %uchar %false %uchar_1 %uchar_0 OpLine %3 410 12 %25 = OpSelect %uchar %true %uchar_1 %uchar_0 OpLine %3 410 12 %26 = OpCompositeExtract %uint %23 0 %27 = OpBitcast %int %26 OpLine %3 410 12 OpSelectionMerge %28 None OpSwitch %27 %29 0 %30 1 %31 %29 = OpLabel OpLine %3 409 14 OpUnreachable %30 = OpLabel OpLine %3 411 20 %32 = OpSelect %uchar %false %uchar_1 %uchar_0 OpLine %3 409 8 OpBranch %28 %31 = OpLabel OpLine %3 410 17 %33 = OpCompositeExtract %int %23 1 OpLine %3 413 4 OpBranch %28 %28 = OpLabel %34 = OpPhi %uchar %32 %30 %25 %31 OpBranch %35 %35 = OpLabel OpLine %3 413 4 %36 = OpINotEqual %bool %34 %uchar_0 OpSelectionMerge %37 None OpBranchConditional %36 %38 %39 %38 = OpLabel OpLine %3 413 4 OpBranch %37 %39 = OpLabel OpBranch %37 %37 = OpLabel OpLine %2 21 1 OpReturn OpFunctionEnd %1 = OpFunction %void None %9 %40 = OpLabel OpLine %2 19 0 %41 = OpFunctionCall %void %compute_shader__main_cs OpReturn OpFunctionEnd

</details>

## System Info

I'm not sure that this is relevant, given this is a compiler side issue, but for completeness:

Windows 10
Ryzen 5 3600
Nvidia Geforce GTX 1050ti

created time in 6 hours

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 10dd1c059847e26db1721591914a812ad0f37815

Deploying to gh-pages from @ 8c05636f5328e1ea5c88194e64c8e657ce572524 🚀

view details

push time in 8 hours

pull request commentEmbarkStudios/rust-gpu

Upgrade wgpu

I've also tried to enable validation again, without success

Naga still chokes on our shaders, with exceedingly unhelpful error messages.

DJMcNab

comment created time in 14 hours

PR opened EmbarkStudios/rust-gpu

Upgrade wgpu

Wgpu 0.9 has released, now under MIT/Apache 2.0 🎉

We can't remove MPL-2.0 from the deny.toml, because wgpu_subscriber is still under MPL.

+81 -29

0 comment

3 changed files

pr created time in 14 hours

PR opened EmbarkStudios/rust-gpu

fix NO_SPIRV_OPT
+1 -1

0 comment

1 changed file

pr created time in 15 hours

pull request commentEmbarkStudios/rust-gpu

Cargo update

Yeah, I did try using wgpu 0.8, but the timer was broken for me too - haven't looked into what's wrong yet though.

khyperia

comment created time in 2 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 5f5619ade3b80526e184635f41e8f5edb33213a9

Deploying to gh-pages from @ 8924fe7b4cc552cf764819a028d6c23ad983b3db 🚀

view details

push time in 2 days

push eventEmbarkStudios/rust-gpu

eddyb

commit sha 7440a959197bf47035b713018cf538c945b2b013

Deploying to gh-pages from @ efd97e6d22a2e6655e0ada9ac9bff366a2b9da75 🚀

view details

push time in 2 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha efd97e6d22a2e6655e0ada9ac9bff366a2b9da75

Fix issue with --disassemble-entry

view details

push time in 2 days

delete branch EmbarkStudios/rust-gpu

delete branch : fix-entry-point-issue

delete time in 2 days

PR merged EmbarkStudios/rust-gpu

Fix issue with --disassemble-entry

When testing some other stuff, I hit this really silly issue - OpEntryPoint has the interface variables tacked onto its operands, so operands.last is only going to be the name if there's no interface variables :|

+2 -1

0 comment

1 changed file

khyperia

pr closed time in 2 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha b307da9d48f8114db6b2d6cd56874723d4d8c4a4

Deploying to gh-pages from @ db5e5fd336be296949adb51e052a29ea39abbbe1 🚀

view details

push time in 3 days

MemberEvent

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 78dcba768abf2823c9b7a2c406cbbd49558f8d88

Deploying to gh-pages from @ 04dfa80266b3efd0f44acfa941e6a20a16bf00ae 🚀

view details

push time in 5 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 485db48f1d601cb1bf695bcd7929801bc7015e09

Deploying to gh-pages from @ f7ac6a09e78ad58ae52375f2a246db68b59abdc7 🚀

view details

push time in 5 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 0d892767377e02238beb6a27ced68bcc28b2958c

Deploying to gh-pages from @ e1a000d408dc14d5bca727762873aae57b822549 🚀

view details

push time in 5 days

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 03dbb33e58b7d3fbebf8d830d8b92e05b84446ac

Deploying to gh-pages from @ fff2b9bce144820fe142e2a0c781da6c53abeb61 🚀

view details

push time in 5 days

startedkhyperia/cargo-space

started time in 5 days

pull request commentEmbarkStudios/rust-gpu

Use `ControlFlow::Poll` for the Mouse shader

Before:

https://user-images.githubusercontent.com/36049421/121875193-17ec7a80-cd00-11eb-8aa4-6e2f9a726e19.mp4

After:

https://user-images.githubusercontent.com/36049421/121875225-2044b580-cd00-11eb-81f4-aca07c5ea624.mp4

DJMcNab

comment created time in 6 days

issue commentEmbarkStudios/rust-gpu

.abs() and .signum() cause 64-bit integer instruction generation

@khyperia I opened a PR for it awhile ago https://github.com/rust-num/num-traits/pull/207. I've sent them a friendly ping to look at it again.

hrydgard

comment created time in 6 days

PR opened EmbarkStudios/rust-gpu

Use `ControlFlow::Poll` for the Mouse shader

I thought that the mouse shader was extremely resource intensive because it was so laggy

However, it turns out that it was just because it was using Wait

+23 -2

0 comment

2 changed files

pr created time in 6 days

pull request commentEmbarkStudios/rust-gpu

Use bytemuck for the push constants

it landed!

DJMcNab

comment created time in 8 days

PR opened EmbarkStudios/rust-gpu

Reviewers
Fix the output filename collision warning

This works simply by naming the binary crate anything other than the name of the lib, which is example-runner-wgpu. As far as I know, the warning started in https://github.com/EmbarkStudios/rust-gpu/pull/215

Since there is only one binary crate in the package, the command to run the package (cargo run -p example-runner-wgpu --release) maintains the same behaviour

The cargo issue is https://github.com/rust-lang/cargo/issues/6313

This warning caused problems for me in testing https://github.com/Lokathor/bytemuck/pull/67 since I didn't notice the warning that my patch was not applied (for those interested, bytemuck main is on version 1.6.1-alpha.0, but I was depending on version 1.6.0 from crates.io)

+0 -0

0 comment

1 changed file

pr created time in 8 days

pull request commentEmbarkStudios/rust-gpu

Use bytemuck for the push constants

If https://github.com/Lokathor/bytemuck/pull/67 lands, then we won't need to have this behind a feature

DJMcNab

comment created time in 8 days

startedkhyperia/khyperia.com

started time in 8 days

PR opened EmbarkStudios/rust-gpu

Use bytemuck for the push constants
+34 -8

0 comment

5 changed files

pr created time in 8 days

issue closedEmbarkStudios/rust-gpu

Following Getting Started hits error

<!-- Thank you for filing a bug report! 🐛 -->

Expected Behaviour

Following the getting started build from https://embarkstudios.github.io/rust-gpu/book/building-rust-gpu.html, I expected to see the build getting started project.

Example & Steps To Reproduce

  1. I followed the getting started guide here: https://embarkstudios.github.io/rust-gpu/book/building-rust-gpu.html
  2. I didn't have rust installed (yes, this was my first time), so I ran brew install rust (and brew install spirv-tools)
  3. I then ran cargo run --bin example-runner-wgpu
  4. It crashed with the error:
error[E0277]: `[&str; 5]` is not an iterator
  --> examples/runners/wgpu/build.rs:30:15
   |
30 |           .args([
   |  _______________^
31 | |             "run",
32 | |             "--release",
33 | |             "-p",
34 | |             "example-runner-wgpu-builder",
35 | |             "--target-dir",
36 | |         ])
   | |_________^ expected an implementor of trait `IntoIterator`
   |
   = note: the trait bound `[&str; 5]: IntoIterator` is not satisfied
   = note: required because of the requirements on the impl of `IntoIterator` for `[&str; 5]`
help: consider borrowing here
   |
30 |         .args(&[
31 |             "run",
32 |             "--release",
33 |             "-p",
34 |             "example-runner-wgpu-builder",
35 |             "--target-dir",
 ...

System Info

Mac OSX 11.4 rustc -V: rustc 1.52.1 spir-val --version: comand not found: spir-val -- not sure how to get that going?

Perhaps it's because I don't have my machine configured properly yet? ... but I also see no way of working out how to configure it.

closed time in 8 days

alecmce

issue commentEmbarkStudios/rust-gpu

Following Getting Started hits error

Yes, that does it. Curious that homebrew borks the install. Oh well, thanks for the help.

alecmce

comment created time in 8 days

issue commentEmbarkStudios/rust-gpu

Following Getting Started hits error

I suspect the root cause issue is brew install rust.

rustc -V giving rustc 1.52.1 suggests that your setup is ignoring the rust-toolchain file at the root, presumably because you are not using rustup.

However, that being said, IntoIterator for [&str; 5] should be present in that version of rustc, so something else strange is afoot - that is, the rustc -V line is extremely confusing

I'd recommend installing rustup from https://rustup.rs/ and trying again.

alecmce

comment created time in 8 days