Open A-R-M opened 4 years ago
If you have time can you pull the code from the wgpu repo to test the examples? The best example to test is likely water
or shadow
. It's my guess that metal 1 isn't fully supported by webgpu possibly. I don't have a metal 1 macbook to test with either. :(
Related to the array constants in the equirectangular_to_cube_faces_vert shader.
Example:
const vec2[6] verts = {
vec2(-1.0, -1.0),
vec2(1.0, -1.0),
vec2(-1.0, 1.0),
vec2(-1.0, 1.0),
vec2(1.0, -1.0),
vec2(1.0, 1.0)
};
Compiles to:
constant spvUnsafeArray<float2, 6> _53 = spvUnsafeArray<float2, 6>({ float2(-1.0), float2(1.0, -1.0), float2(-1.0, 1.0), float2(-1.0, 1.0), float2(1.0, -1.0), float2(1.0) });
wgpu-rs Version: commit d0825a219511c28bf74f8cbef9056b55fde4e04e
wgpu Version: commit a0ed09a6a83dc0d16c6ad711cf139a5fcfbb9c35
Just tested them… and you’re absolutely right! 😂
While simple examples like cube
look exactly like they should, water
and shadow
are a completely different story.
Starting with shadow
, I get no runtime errors, but the resulting window is a complete mess. It also causes my Mac to completely lock up and then kernel panic if I leave it animating for more than a few seconds. 😂 I managed to take some screenshots after a few kernel panics:
As for water
, it tries but fails to open a window, instead giving the following errors and then crashing:
$ RUST_BACKTRACE=full cargo run --example water
warning: missing documentation for an associated function
--> src/lib.rs:1016:5
|
1016 | / pub unsafe fn create_surface_from_core_animation_layer(
1017 | | &self,
1018 | | layer: *mut std::ffi::c_void,
1019 | | ) -> Surface {
... |
1036 | | }
1037 | | }
| |_____^
|
note: the lint level is defined here
--> src/lib.rs:6:9
|
6 | #![warn(missing_docs)]
| ^^^^^^^^^^^^
warning: 1 warning emitted
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
Running `target/debug/examples/water`
[2020-07-17T12:50:07Z ERROR gfx_backend_metal::device] Error compiling the shader CompilationFailed("Compilation failed: \n\n<program source>:17:4: error: \'early_fragment_tests\' attribute requires metal language to be 2.0 or higher\n[[ early_fragment_tests ]] fragment main0_out main0(main0_in in [[stage_in]])\n ^~~~~~~~~~~~~~~~~~~~\n")
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Other', /Users/username/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/a0ed09a/wgpu-core/src/device/mod.rs:2423:17
stack backtrace:
0: 0x10daa68bf - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8ad47541fb823094
1: 0x10dac932e - core::fmt::write::he23e9bd6497f06c3
2: 0x10daa45b7 - std::io::Write::write_fmt::h91528f1131e6004e
3: 0x10daa872a - std::panicking::default_hook::{{closure}}::h1983f014a45a477e
4: 0x10daa846c - std::panicking::default_hook::hb0d9b93b5be8b120
5: 0x10daa8dd8 - std::panicking::rust_panic_with_hook::h9f3faafe0983de5c
6: 0x10daa8972 - rust_begin_unwind
7: 0x10dac706f - core::panicking::panic_fmt::h0a2d1b3ca0b14316
8: 0x10dac6eb5 - core::option::expect_none_failed::haea18d6ed867f4e9
9: 0x10d0da8a6 - core::result::Result<T,E>::unwrap::h021efc7c95cba597
10: 0x10d294483 - wgpu_core::device::<impl wgpu_core::hub::Global<G>>::device_create_render_pipeline::hc70bb9355a5dc22c
11: 0x10d0d2f07 - wgpu::backend::direct::<impl wgpu::Context for wgpu_core::hub::Global<wgpu_core::hub::IdentityManagerFactory>>::device_create_render_pipeline::he800cf8a07454223
12: 0x10d1fc57b - wgpu::Device::create_render_pipeline::h1dbfe7ff72aceb6b
13: 0x10cec1d8c - <water::Example as water::framework::Example>::init::ha37bda679d66fc70
14: 0x10ce79c12 - water::framework::start::h115bb9aa3b426cf5
15: 0x10ce7a975 - water::framework::run::hb073f255cbaab748
16: 0x10cec2a58 - water::main::h6a5a0d897487ccb0
17: 0x10ce89b8e - std::rt::lang_start::{{closure}}::h0adcbab3cb76d8c8
18: 0x10daa9139 - std::rt::lang_start_internal::h795af50241e12334
19: 0x10ce89b71 - std::rt::lang_start::h8e92768106f5d93b
20: 0x10cec2a82 - main
[2020-07-17T12:50:07Z ERROR gfx_memory::heaps] Heaps not completely freed before drop. Utilization: MemoryHeapUtilization { utilization: MemoryUtilization { used: 8126464, effective: 4460800 }, size: 18446744073709551615 }
[2020-07-17T12:50:07Z ERROR gfx_memory::heaps] Heaps not completely freed before drop. Utilization: MemoryHeapUtilization { utilization: MemoryUtilization { used: 16777216, effective: 346368 }, size: 268435456 }
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(15872) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(126976) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(31744) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(253952) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(63488) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(507904) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(1015808) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(2031616) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(329728) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(256) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::general] Memory leak: SizeEntry(1920000) is still used
[2020-07-17T12:50:07Z ERROR gfx_memory::allocator::linear] Not all allocations from LinearAllocator were freed
[2020-07-17T12:50:07Z ERROR gfx_descriptor::allocator] DescriptorAllocator is dropped
[2020-07-17T12:50:07Z ERROR gfx_backend_metal::command] Command buffer not released properly!
Of particular interest is this part of the error:
Compilation failed: \n\n<program source>:17:4: error: \'early_fragment_tests\' attribute requires metal language to be 2.0 or higher
which I believe confirms your suspicion. 😩
As a side note the custom pipeline example works because it's pretty basic. You can write out some of your own pipelines and shaders which should work fine as long as you stay within the confines of metal 1. I could fix the issue above by possibly using a uniform and passing in the different const arrays that way, but I'm not sure I want to try and support metal 1 as it has some limitations that I plan on breaking fairly soon.. The biggest one being the lack of support for arrays of textures.
Hi everybody! There is a lot of stuff mixed up here.
@A-R-M @StarArawn
Compilation failed: \n\n
:47:43: error: no matching conversion for functional-style cast from \'void\' to
IIRC, SPIRV-Cross has issues with arrays on Metal. Things like https://github.com/KhronosGroup/SPIRV-Cross/issues/1394 (there are more issues in there). Be careful with fixed-size const arrays, basically (i.e. try not to use them). As we are replacing SPIRV-Cross in the long run with Naga, we'll strive to not fail on that, but Naga is still a long way to go before we can use it.
Starting with shadow, I get no runtime errors, but the resulting window is a complete mess.
This is https://github.com/gfx-rs/wgpu/issues/103, which has been known for a while. I concluded this to be a driver issue, and it was indeed fixed in one of the OS updates after 10.11. Right now I'm on 10.15, and it woks correctly.
It's unlikely that you'll hit the issue unless you use texture arrays with depth comparison.
Compilation failed: \n\n
:17:4: error: \'early_fragment_tests\' attribute requires metal language to be 2.0 or higher\n[[ early_fragment_tests ]] fragment main0_out main0(main0_in in [[stage_in]])\n
The water example also presumably fails because SPIRV-Cross fails to check for MSL version when it tries to add the early_fragment_tests
attribute. Also @StarArawn filed it to us as https://github.com/gfx-rs/wgpu-rs/issues/445.
It's easy to workaround - just make sure your SPIRV don't use this attribute, for now.
This is gfx-rs/wgpu#103, which has been known for a while. I concluded this to be a driver issue, and it was indeed fixed in one of the OS updates after 10.11. Right now I'm on 10.15, and it woks correctly.
Thanks for that link to the issue for the driver bug! At this point, it seems like staying on 10.11 is far too limiting; I have an SSD on the way (APFS runs horribly on HDDs) and will just update to 10.15 as soon as possible. 😅
bd4300ffbc651aeea8e625606645d90021cad83a
When attempting to run the
hello-cube
example, I get the following output:I’m guessing that error is related to me using OS X v10.11 El Capitan (the very first version of macOS to support Metal, and thus is using Metal 1).
Sidenote: The other examples run on this computer (with warnings), except for
benchmark
which gives a compile time error.