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 353

Rust implementation of SPIR-V module processing functionalities

khyperia/CudaSharp 157

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 commentEmbarkStudios/rust-gpu

Can not call function with sub-slice as argument

Unfortunately yeah, SPIR-V does not have an easy representation of subslices - we would need to tack on a (offset, length) pair to all regular arrays to support slicing, which then would change the ABI of the generated SPIR-V to be significantly different than what rustc tells us to do, which we've managed to avoid doing so far (it gets really, really complicated).

Hopefully at some point we can support slicing, though!

SiebenCorgie

comment created time in 4 days

issue commentEmbarkStudios/rust-gpu

Warn when something derives `Debug`

Unfortunately it's not that simple. We need to consider all sorts of edge cases - for example, saying "you can't use #[derive(Debug)]" when directly referencing something in std::fmt is incorrect, confusing, and misleading.

SiebenCorgie

comment created time in 5 days

issue commentEmbarkStudios/rust-gpu

Warn when something derives `Debug`

Unfortunately, this is a really difficult problem to solve (... as is everything else that we haven't fixed yet :stuck_out_tongue:). The issue is that rust-gpu never sees anything like #[derive(Debug)], but instead a heap of rust code that looks exactly like the user wrote it, with no way to tell from what macro it was generated from, or even if it's generated at all. All it sees is some super wacky code that definitely won't work on the GPU, and so the only thing it can do is error on the bad code. Because of this, unfortunately, this issue will likely not be fixed any time soon.

This issue is mentioned in #744.

SiebenCorgie

comment created time in 5 days

issue commentEmbarkStudios/rust-gpu

Support Option<T>

(meta note: I believe you discussed those questions on discord with eddyb after you posted this, so I won't answer again here - let me know if I'm mistaken and I can give answers here)

termhn

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentgfx-rs/naga

[spv-in] new block parser

 struct LookupVariable { struct LookupExpression {     handle: Handle<crate::Expression>,     type_id: spirv::Word,+    /// The block id this expression belongs to+    block_id: spirv::Word,

theoretically you could define a label with id 0?

In SPIR-V, id 0 is illegal: in the section 2.3 Physical Layout of a SPIR-V Module and Instruction, Table 1. First Words of Physical Layout, section on Bound, it states:

Bound; where all <id>s in this module are guaranteed to satisfy 0 < id < Bound Bound should be small, smaller is better, with all <id> in a module being densely packed and near 0.

note the < - it's 0 < id, not 0 <= id.

JCapucho

comment created time in 8 days

issue commentEmbarkStudios/rust-gpu

spirv-val fails for a module using derived `Eq::eq` to the target `spirv-unknown-vulkan1.2`

right now only Input/Output storage class variables are listed in entrypoints.

This isn't correct - to clarify, we support adding all relevant variables in the entrypoint function to the interface list for versions >= 1.4. That code is here.

The issue is specifically with constants that contain pointers to other constants, which are generated as Private variables here. The issue here is that there is a reference taken to a constant, &T(0) (Eq takes its arguments by reference), and that constant needs to be added to the interface list, even though it's not part of any interface.

hatoo

comment created time in 10 days

delete branch EmbarkStudios/rust-gpu

delete branch : specializer-repro

delete time in 11 days

push eventkhyperia/Clam

khyperia

commit sha 7cc00b7c842f88416af42646903858d4203fb5d7

update deps

view details

push time in 11 days

push eventEmbarkStudios/rust-gpu

Ashley Hauck

commit sha eeb67ae7489e5df03231f73d108a8f2feae2ca1a

Replace <const INTERSECTION: u32> with two functions (#750) * Replace <const INTERSECTION: u32> with two functions * Fix doc URLs

view details

push time in 11 days

delete branch EmbarkStudios/rust-gpu

delete branch : ray_query-no-const-generic

delete time in 11 days

PR merged EmbarkStudios/rust-gpu

Replace <const INTERSECTION: u32> with two functions

Also add documentation, and clean up some overly verbose or inefficient code.

Fixes #745

+428 -110

0 comment

13 changed files

khyperia

pr closed time in 11 days

issue closedEmbarkStudios/rust-gpu

Ray Query intersection types

RayQuery::get_intersection_type and friends take const generic. Would be nice to expose these as enum similar to Scope for example.

enum RayQueryIntersection {
   Candidate = 0,
   Committed = 1,
}

The other part would be the return value, which depends on the used intersection type. I'm not sure how to expose these properly, beside maybe specialize the get_intersection_type and use newtypes or just keep the u32 and just expose RayQueryCommittedIntersectionNoneKHR, etc as consts

Specification: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_ray_query.asciidoc

closed time in 11 days

msiglreith

push eventEmbarkStudios/rust-gpu

khyperia

commit sha 9642b1532f8835e4cf490c751198bac1d7f264ad

Fix doc URLs

view details

push time in 11 days

PR opened EmbarkStudios/rust-gpu

Reviewers
Replace <const INTERSECTION: u32> with two functions

Also add documentation, and clean up some overly verbose or inefficient code.

Fixes #745

+428 -110

0 comment

13 changed files

pr created time in 11 days

create barnchEmbarkStudios/rust-gpu

branch : ray_query-no-const-generic

created branch time in 11 days

issue commentEmbarkStudios/rust-gpu

Ray Query intersection types

Looking into this, I don't see any use case for using the const generics version - seems like just writing out two methods for every <const INTERSECTION> is the way to go. Docs and whatnot can be vastly improved that way, too.

I might be missing something, though, feel free to point something out.

msiglreith

comment created time in 11 days

push eventEmbarkStudios/rust-gpu

Ashley Hauck

commit sha 92dc64bd067b0761b4189e8efde1a11ed4c503e2

Make byte addressable buffer take &self, add support for matrix (#749)

view details

push time in 12 days

delete branch EmbarkStudios/rust-gpu

delete branch : bab-byref-and-matrix

delete time in 12 days

issue closedEmbarkStudios/rust-gpu

Matrix support for buffer load/store

Would be nice to support SpirvType::Matrix for the BufferLoad/Store intrinsics as well. I think this can be covered internally by store/load_vec_or_arr.

closed time in 12 days

msiglreith

issue openedKhronosGroup/SPIRV-Registry

OpRayQueryCommittedTypeKHR is mentioned in SPV_KHR_ray_query, but defined nowhere

There's a bunch of phrases like this:

If Intersection is RayQueryCommittedIntersectionKHR, there must be a current committed intersection (see OpRayQueryCommittedTypeKHR).

However, OpRayQueryCommittedTypeKHR isn't defined anywhere: grepping through this repository, the only mention is in the SPV_KHR_ray_query doc, in the above phrase. Googling, there are two hits, which are the document and the raw html version.

What is it? Where is it defined?

created time in 12 days

create barnchEmbarkStudios/rust-gpu

branch : bab-byref-and-matrix

created branch time in 12 days

push eventEmbarkStudios/rust-gpu

Ashley Hauck

commit sha 95da8981ad12ebf3dabd7c6f028f0b5bdf9568bc

Add load/store_unchecked to ByteAddressableBuffer without bounds check (#746)

view details

push time in 15 days

delete branch EmbarkStudios/rust-gpu

delete branch : bab-unchecked

delete time in 15 days

create barnchEmbarkStudios/rust-gpu

branch : bab-unchecked

created branch time in 15 days

pull request commentTraverse-Research/rspirv-reflect

Add OpTypeArray to get_descriptor_type

Ah, then I guess no follow-up? is_bindless is currently set to true for StructuredBuffer<uint> test[4]; - it's kind of wishy washy, yeah, not sure what is_bindless actually means/is used for

khyperia

comment created time in 17 days