Vulkan-ValidationLayers VS Rust-CUDA

If this works then it might actually be a game bug and the game I guess passes invalid shaders when the cache exists... but it seems to work fine on windows vulkan drivers. You could try to run the game with https://github.com/KhronosGroup/Vulkan-ValidationLayers

For debugging these kinds of issues, I would recommend enabling the synchronization validation layer.

I would use the debugger to produce a stack trace and look into the validation layers source code. https://github.com/KhronosGroup/Vulkan-ValidationLayers Then I would either file an issue or make a PR there.

Currently validation layers might generate false-positive errors: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/3450

A'rightey... I was able to reproduce this issue with Sascha Willems basic triangle example, so I am fairly certain, that this is a bug. I've opened an issue.

I am really at loss here, I found this issue but it doesn't really help me (I am starting to doubt it's even possible, maybe I'm a clown and doing it wrong...)

Can you post a reproduction case at https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues so we can take a look at it.

Which is why a GPU debugger with frame tracing is so much better option.

By the way, there are actually ways to expose a print function on shader code, provided there is driver support.

https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...

Huh yeah. Looking through the header the function you want works with c but there are others using c++ features. The reason given is understandable.

Source code [here](https://github.com/ihawn/RTracer) if anyone is interested in taking a look or giving feedback. As a side question, does anyone have any general advise on getting GPU compute working with rust? I tried [this project](https://github.com/Rust-GPU/Rust-CUDA) but had a bunch of issues (And it doesn't look like an active repo anyways)

You have this https://github.com/Rust-GPU/Rust-CUDA

What I'm trying to do is check out https://github.com/Rust-GPU/Rust-CUDA for a class project.

Be warned, NON_BLOCKING streams do not fully synchronize with sync host to device copies. They are not guaranteed to actually finish by the time they return. Meaning its possible to initiate a copy, then initiate a kernel launch, and have the copy be unfinished by the time the kernel is launched. This caused so many confusing bugs that i personally decided to stop using NON_BLOCKING altogether in rust-cuda. https://github.com/Rust-GPU/Rust-CUDA/issues/15

- Cuda is not doing by FFI linking, instead is compiling CUDA code natively in Rust https://github.com/Rust-GPU/Rust-CUDA and even if it not complete as the C++ SDK is more than a toy

Given your criteria, you might want to consider (modern) C++.

* Fast - in many cases faster than Rust, although the difference is inconsequential relative to Python-to-Rust improvement I guess.

* _Really_ utilize CUDA, OpenCL, Vulcan etc. Specifically, Rust GPU is limited in its supported features, see: https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/... ...

* Host-side use of CUDA is at least as nice, and probably nicer, than what you'll get with Rust. That is, provided you use my own Modern C++ wrappers for the CUDA APIs: https://github.com/eyalroz/cuda-api-wrappers/ :-) ... sorry for the shameless self-plug.

* ... which brings me to another point: Richer offering of libraries for various needs than Rust, for you to possibly utilize.

* Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.

There are downsides, of course, but I was just applying your criteria.

Technically, yes. There are crates for OpenCL and CUDA, although official ROCm support does not exist yet.