Hi, I got segmentation fault with an example using textures in Instancing tutorial. Does this only happen on me? I'm using Wayland and GNOME3 on Manjaro Linux.

Note that my window manager behaves a bit strangely in that it resizes windows after it is created. I suspect the resize is the cause, so I want to know whether this is reproducible on other environments or a very rare issue.

What I did was adding this section to code/beginner/tutorial7-instancing/Cargo.toml

[[example]]
name = "tutorial7-texture"
path = "examples/texture_instances.rs"

and running the command below:

$ cargo run --example tutorial7-texture
warning: unused variable: `instance_buffer_size`
   --> code/beginner/tutorial7-instancing/examples/texture_instances.rs:393:13
    |
393 |         let instance_buffer_size = instance_data.len() * std::mem::size_of::<cgmath::Matrix4<f32>>();
    |             ^^^^^^^^^^^^^^^^^^^^ help: consider prefixing with an underscore: `_instance_buffer_size`
    |
    = note: `#[warn(unused_variables)]` on by default

warning: field is never read: `instances`
   --> code/beginner/tutorial7-instancing/examples/texture_instances.rs:278:5
    |
278 |     instances: Vec<Instance>,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/examples/tutorial7-texture`
Segmentation fault (core dumped)

The code described in the SwapChain Tutorial panics with the following output:

thread 'main' panicked at 'Failed to focus input context: XError { description: "BadDrawable (invalid Pixmap or Window parameter)", error_code: 9, request_code: 149, minor_code: 4 }', src/libcore/result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Running with backtrace gives the following output:

thread 'main' panicked at 'Failed to focus input context: XError { description: "BadDrawable (invalid Pixmap or Window parameter)", error_code: 9, request_code: 149, minor_code: 4 }', src/libcore/result.rs:1165:5
stack backtrace:
   0:     0x5634fb192674 - backtrace::backtrace::libunwind::trace::hda41dbcdfba36aa0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1:     0x5634fb192674 - backtrace::backtrace::trace_unsynchronized::h1a8d6e1f8cb3f5d4
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2:     0x5634fb192674 - std::sys_common::backtrace::_print_fmt::h610c4127487e10da
                               at src/libstd/sys_common/backtrace.rs:76
   3:     0x5634fb192674 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0722dc552e01bd1d
                               at src/libstd/sys_common/backtrace.rs:60
   4:     0x5634fb1b429c - core::fmt::write::h01edf6dd68a42c9c
                               at src/libcore/fmt/mod.rs:1030
   5:     0x5634fb18fb77 - std::io::Write::write_fmt::hf15985f193f03c04
                               at src/libstd/io/mod.rs:1412
   6:     0x5634fb194b85 - std::sys_common::backtrace::_print::hd8d5d08a1795e743
                               at src/libstd/sys_common/backtrace.rs:64
   7:     0x5634fb194b85 - std::sys_common::backtrace::print::hf89a79e3921a2366
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x5634fb194b85 - std::panicking::default_hook::{{closure}}::h3a8f42beb3bb8ae3
                               at src/libstd/panicking.rs:196
   9:     0x5634fb194876 - std::panicking::default_hook::h8f803b0bc31a5c37
                               at src/libstd/panicking.rs:210
  10:     0x5634fb195285 - std::panicking::rust_panic_with_hook::h825f041245da8739
                               at src/libstd/panicking.rs:473
  11:     0x5634fb194e22 - std::panicking::continue_panic_fmt::hbe0378e33481e81b
                               at src/libstd/panicking.rs:380
  12:     0x5634fb194d16 - rust_begin_unwind
                               at src/libstd/panicking.rs:307
  13:     0x5634fb1b069a - core::panicking::panic_fmt::h527855ce0bc891f6
                               at src/libcore/panicking.rs:85
  14:     0x5634fb1b0797 - core::result::unwrap_failed::ha8b77e6004f0ba38
                               at src/libcore/result.rs:1165
  15:     0x5634fab0c981 - core::result::Result<T,E>::expect::ha3dc71e3c3df67a5
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/result.rs:960
  16:     0x5634fab1ca05 - winit::platform_impl::platform::x11::event_processor::EventProcessor<T>::process_event::h99f30c7b91bd4e01
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/platform_impl/linux/x11/event_processor.rs:868
  17:     0x5634fab2a9f5 - winit::platform_impl::platform::x11::EventLoop<T>::drain_events::ha2600fbdf631ab40
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/platform_impl/linux/x11/mod.rs:402
  18:     0x5634fab29500 - winit::platform_impl::platform::x11::EventLoop<T>::run_return::h09d5b07aee8bc6fe
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/platform_impl/linux/x11/mod.rs:260
  19:     0x5634fab2ae0b - winit::platform_impl::platform::x11::EventLoop<T>::run::h3a8df3fe1aebdcb2
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/platform_impl/linux/x11/mod.rs:386
  20:     0x5634fab2d57e - winit::platform_impl::platform::EventLoop<T>::run::h22021ac5f0e88e76
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/platform_impl/linux/mod.rs:644
  21:     0x5634faaf72c4 - winit::event_loop::EventLoop<T>::run::he611cc003761aeb0
                               at /home/kunal/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0/src/event_loop.rs:148
  22:     0x5634faaffd97 - try_wgpu::main::hf5dd9c0cb7449a73
                               at src/main.rs:12
  23:     0x5634fab34ec0 - std::rt::lang_start::{{closure}}::h9e5098d20c41fd21
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  24:     0x5634fb194cb3 - std::rt::lang_start_internal::{{closure}}::ha04574f12d97cbe2
                               at src/libstd/rt.rs:49
  25:     0x5634fb194cb3 - std::panicking::try::do_call::h7c2a8488f72db90c
                               at src/libstd/panicking.rs:292
  26:     0x5634fb19898a - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:80
  27:     0x5634fb19577d - std::panicking::try::hc3a9b5da4250385d
                               at src/libstd/panicking.rs:271
  28:     0x5634fb19577d - std::panic::catch_unwind::hf27600bf8c37809a
                               at src/libstd/panic.rs:394
  29:     0x5634fb19577d - std::rt::lang_start_internal::h409d4f2fe51133b0
                               at src/libstd/rt.rs:48
  30:     0x5634fab34e99 - std::rt::lang_start::haf1cb75fea9702a9
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  31:     0x5634fab0045a - main
  32:     0x7f1645cf2b6b - __libc_start_main
  33:     0x5634faabb19a - _start
  34:                0x0 - <unknown>

I am running it on Ubuntu 19.04

Any idea why the example in this page is flickering and with a dark blue background?

I'm on a Mac M1, and this is with Chrome Version 103.0.5060.134.

https://user-images.githubusercontent.com/210002/181449852-83fcd1ba-be76-4199-abbf-ec0cdd6852aa.mov

Now that almost all wgpu examples have been ported to WGSL, would you consider writing the tutorial shaders in WGSL too?

I am aware of the existing discussion in #137, just wanted to bring this up again in the light of said reddit post.

thanks for your tutorial it helped me a lot

I would be happy to contribute this info. I don't have a strong opinion on where the best place would be or what else would need to be added so feel free to request changes or if you want also modify it yourself.

I would like to add a few code examples but I'm not sure how to best display the alignment/ memory regions in markdown.

Hello, I have been trying to learn wgpu by following the examples and I have encountered a problem and I was not able to determine the issue. I'm on Windows 11 and using a NVIDIA graphics card (RTX 2060). I'm able to draw colors, but I'm unable to draw the triangle and I have done everything thats been done in the examples. I have used different backends like DX11 DX12 Vulkan GL and that didnt change anything. I have also tried to change the match arms order, as I thought it may be the cause. But still I was not able to understand it. What can be the issue ?

As you can see, I have created a windows that has colors inside.

I have done everything in the examples and as you can see, I have attached my render_pipeline to my render_pass

as you may have guessed, I'm not very experienced in graphics programming, and If the question seems very basic, I'm sorry.

Core tasks

• [x] Migrate tutorial code
• [x] Migrate showcases
• [x] Add link to wasm compile steps
• [x] Add link to element/matrix chat room

Bonus tasks

• [x] Evaluate switch to WGSL
• [ ] Test out wasm build on tutorial 5

Hi, I'm the maintainer of the rust-tutorials github org. I had a contributor who was starting on a wgpu tutorial, but they had some personal issues and essentially won't be able to continue the work.

Luckily, I was pointed to your wgpu tutorial here!

I'd love to know how we might work together. I could just have the rust-tutorials/learn-wgpu readme link to your repo, or if you want I can make you a maintainer of that repo and you can move your stuff in and merge the two projects, or however you feel is best.

[2021-04-17T21:23:10Z ERROR gfx_backend_vulkan] 
    VALIDATION [VUID-VkRenderPassBeginInfo-framebuffer-04627 (1158829633)] : Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-04627 ] Object 0: handle = 0xb5f68b000000000e, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x45125641 | vkCmdBeginRenderPass(): Image view #0 created from an image with usage set as 0x11, but image info #0 used to create the framebuffer had usage set as 0x10 The Vulkan spec states: If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of the pAttachments member of a VkRenderPassAttachmentBeginInfo structure included in the pNext chain must be a VkImageView with an inherited usage equal to the usage member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://vulkan.lunarg.com/doc/view/1.2.170.0/windows/1.2-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-04627)
    object info: (type: RENDER_PASS, hndl: 13111820197252038670)

Getting a lot of these running tutorial 2 (not tutorial 1).

cd code/beginner/tutorial2-swapchain
cargo run --bin tutorial2-swapchain

I saw another closed issue with another error message, where you requested a trace. I captured one, allowing the example to run ~5 seconds, attached: trace.zip.

Also, vulkan configuration says I have (might help?):

Vulkan Development Status:

• Layers override: "Validation" configuration
• $VULKAN_SDK SDK path: C:\VulkanSDK\1.2.170.0
• Vulkan Loader version: 1.2.170
• User-Defined Layers Paths from $VK_LAYER_PATH: None
• User-Defined Layers Paths from Vulkan Configurator: None
• Available Layers:
  • VK_LAYER_NV_optimus (1.2.168)
  • VK_LAYER_OBS_HOOK (1.2.131)
  • VK_LAYER_VALVE_steam_overlay (1.2.136)
  • VK_LAYER_VALVE_steam_fossilize (1.2.136)
  • VK_LAYER_EOS_Overlay (1.2.136)
  • VK_LAYER_EOS_Overlay (1.2.136)
  • VK_LAYER_LUNARG_override (1.2.170)
  • VK_LAYER_LUNARG_api_dump (1.2.170)
  • VK_LAYER_LUNARG_device_simulation (1.2.170)
  • VK_LAYER_LUNARG_gfxreconstruct (1.2.170)
  • VK_LAYER_KHRONOS_synchronization2 (1.2.170 - BETA)
  • VK_LAYER_KHRONOS_validation (1.2.170)
  • VK_LAYER_LUNARG_monitor (1.2.170)
  • VK_LAYER_LUNARG_screenshot (1.2.170)
• Physical Devices:
  • NVIDIA GeForce RTX 2080 Ti (Discrete GPU) with Vulkan 1.2.168

https://sotrh.github.io/learn-wgpu/beginner/tutorial5-textures/#loading-an-image-from-a-file

Basically just following along but I'm getting an error while working through the subsections. I just noticed it when I was at the shader section, but in the tutorial steps the variable diffuse_texture seems to be used for two separate things.

No matter if diffuse_texture is a Texture or DynamicImage I can't seem to access the view or sampler fields.

Not sure if I'm just missing something obvious here, but wanted to bring it up!

In the "The Swapchain" section of the tutorial, the State::new() block calls let size = window.inner_size(); twice. I don't think both calls are needed. Was the call intended to go at the beginning or end of the code block?

https://github.com/sotrh/learn-wgpu/blob/master/docs/beginner/tutorial2-swapchain/README.md#statenew

Actually I've noticed multiple differences between the .md code and your repo. State::new() writes the adapter field into Self = State, which doesn't exist. This field was removed in the repo at https://github.com/sotrh/learn-wgpu/blob/master/code/beginner/tutorial2-swapchain/src/main.rs .

Also the code doesn't compile on wgpu 0.6.

https://github.com/sotrh/learn-wgpu/blob/master/code/beginner/tutorial6-uniforms/src/main.rs#L466 self.queue.write_buffer(&self.uniform_buffer, 0, &bytemuck::cast_slice(&[self.uniforms])); I suspect the & in &bytemuck::cast_slice is redundant and gets silently discarded.

I added a slightly personal instruction when mentioning geometry shader that they should in general not be used. They dramatically reduce performance and in the industry, most people are not using them.

Also I had previously tried to fix some code formating which I had no time to pursue. Those commits can be reverted if you will

The code in the State::new section of the introductory tutorial includes a call to the unsafe create_surface method. I think it would be useful to include a discussion of what is required for this call to be valid and why the usage shown meets these requirements, preferably also with a comment in the source code at that line.

Bumps qs from 6.5.2 to 6.5.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.