How to draw text to a Vulkan renderpass without binding a single texture

How to draw text to a Vulkan renderpass without binding a single texture

Hi, I am trying to get this working but I ran into this error: wgpu error: Validation Error Caused by: In ComputePass::end In a dispatch command, indirect:false Attempted to use Texture with 'Output texture' label (mips 0..1 layers 0..1) with conflicting usages. Current usage TextureUses(STORAGE_READ_WRITE) and new usage TextureUses(RESOURCE). TextureUses(STORAGE_READ_WRITE) is an exclusive usage and cannot be used with any other usages within the usage scope (renderpass or compute dispatch). The thing I defined the usage in shared bind group, so it is either write or read. This is the texture: let output_texture = device.create_texture(&TextureDescriptor { label: Some("Output texture"), size: Extent3d { width: surface_config.width, height: surface_config.height, depth_or_array_layers: 1}, mip_level_count: 1, sample_count: 1, dimension: wgpu::TextureDimension::D2, format: TextureFormat::Rgba8Unorm, usage: TextureUsages::STORAGE_BINDING | TextureUsages::TEXTURE_BINDING, view_formats: &[], }); let output_view = output_texture.create_view(&TextureViewDescriptor::default()); The bind group: let bind_group_layout = device.create_bind_group_layout(&BindGroupLayoutDescriptor { label: Some("Shared bindgroup layout"), entries: &[ BindGroupLayoutEntry { binding: 0, visibility: ShaderStages::COMPUTE, ty: wgpu::BindingType::StorageTexture { access: StorageTextureAccess::WriteOnly, format: TextureFormat::Rgba8Unorm, view_dimension: wgpu::TextureViewDimension::D2 }, count: None, }, BindGroupLayoutEntry { binding: 1, visibility: ShaderStages::FRAGMENT, ty: wgpu::BindingType::Texture { sample_type: wgpu::TextureSampleType::Float { filterable: false }, view_dimension: wgpu::TextureViewDimension::D2, multisampled: false }, count: None, }, ], }); let bind_group = device.create_bind_group(&BindGroupDescriptor { label: Some("Shared bindgroup"), layout: &bind_group_layout, entries: &[ BindGroupEntry { binding: 0, resource: BindingResource::TextureView(&output_view), }, BindGroupEntry { binding: 1, resource: BindingResource::TextureView(&output_view), } ] }); And the render function: let mut encoder = self.device.create_command_encoder(&CommandEncoderDescriptor { label: Some("Compute encoder"), }); { let mut compute_pass = encoder.begin_compute_pass(&ComputePassDescriptor { label: Some("Compute pass"), timestamp_writes: None, }); compute_pass.set_pipeline(&self.compute_pipeline); compute_pass.set_bind_group(0, &self.bind_group, &[]); compute_pass.dispatch_workgroups( (self.surface_config.width + 7) / 8, (self.surface_config.height + 7) / 8, 1, ); } { let frame = self.surface.get_current_texture().unwrap(); let view = frame.texture.create_view(&TextureViewDescriptor::default()); let mut render_pass = encoder.begin_render_pass(&RenderPassDescriptor { label: Some("Render pass"), color_attachments: &[Some(RenderPassColorAttachment { view: &view, resolve_target: None, ops: Operations { load: wgpu::LoadOp::Clear(wgpu::Color::BLACK), store: wgpu::StoreOp::Discard, } })], depth_stencil_attachment: None, timestamp_writes: None, occlusion_query_set: None, }); render_pass.set_pipeline(&self.render_pipeline); render_pass.set_bind_group(0, &self.bind_group, &[]); render_pass.draw(0..6, 0..1); } self.queue.submit(Some(encoder.finish())); I do not really know how to tackle this issue as I am learning the API, help appreciated.

A GPU compute-centric 2D renderer. Contribute to linebender/vello development by creating an account on GitHub.

本書はUnity6から利用可能になったRender Graphを動かしながら、設定や実装方法を習得することが目的です。 今後のデフォルト機能になると思われるRender Graphを使ってRenderPassを実装していきす。 Raster/Compute/Unsafeと3つのそれぞれのサンプルを確認して、基本構造を知ることでRender Graphがシンプルで使いやすいことを確認します。 Gi...

How to draw text to a Vulkan renderpass without binding a single texture

# Super Late Code Meant to blog about this last quarter, but somehow another two months went by and here we are. A while back, I did some work to improve zink performance on tiling GPUs. Namely this entailed adding renderpass tracking into threaded-context, and also implementing command stream reordering, and inlining swapchain resolves, and framebuffer discards, and actually maybe it’s more than just “some” work. All of this amounted to improved performance by reducing memory bandwidth. How much improved performance? All of it. And then, around two months ago, a colleague told me he was no longer going to use zink on his tiling GPU. # Devastated Some of you noticed that the blog has gone quiet in recent times. I’m going to take this opportunity to foist all the blame onto that colleague: to preserve his identity, let’s just call him Gabe. Gabe came to me a few months ago and told me zink was too slow. Vulkan was better. Faster. More “reliable”. I said there’s no way that could be true; I’ve put way more bugs into Vulkan than I have into zink. Unblinking, he stared at me across the digital divide. I task-switched to important whitespace cleanups. Time passed, and I pulled myself together. I compiled some app traces. Analyzed them. Did some deep thinking. There was one place where zink indeed could be less performant than this “Vulkan” thing. The final frontier of driver performance. Some call it graphics heaven. I call it hell. # Web Browsers Chrome is the web browser, and, statistically, everyone uses it. It ships on desktops and phones, embeds in apps, and even allows you to read this blog. Haters will say _No I uSe FiReFoX_ , but they may as well be Netscape users in the year 2000. In the past, Chrome defaulted to using GL, which made testing easy. Now, however, `--disable-features=Vulkan` is needed to return to the comfort of an API so reliable it no longer receives versioned updates. Looking at an apitrace of Chrome, I saw a disturbing rendering pattern that went something like this: * draw some element on a page using multisampled FBO1 * resolve FBO1 to texture1 * composite texture1 onto larger FBO2/texture2 * composite texture2 onto even larger, multisampled FBO3 * resolve FBO3 to swapchain * present In this case, zink would correctly inline the FBO3/swapchain resolve at the end, but the intermediate multisampled rendering on `FBO1` would pay the full performance penalty of storing the multisampled image data and then loading it again for the separate resolve operation. I’d like to say it was simple to inline this intermediate resolve. That I just slapped a single MR into mesa and it magically worked. Unfortunately, nothing is ever that simple. There were minor fixups all over the place. And this brought me to the real insanity. Chrome has bugs too. # Literal Hell Let’s take a concrete example: launch Chrome with `--disable-features=Vulkan` and check out this tiny SVG: chromebug.html This is most likely what you see: The reason you see this is because you are on a big, strong desktop GPU which doesn’t give a shit about load/store ops or uninitialized GPU memory. You’re driving a giant industrial bulldozer on your morning commute: traffic no longer exists and stop signals are fully optional. On a wimpy tiling GPU, however, things are different. Using a recent version of zink, even on a desktop GPU, you can run the same Chrome browser using `ZINK_DEBUG=rp,rploads` to enable the same codepaths used by tilers and also clear all uninitialized memory to red. Now load the same SVG, and you’ll see this: It took nearly a week of pair debugging and a new zink debug mode to prune down test cases and figure out what was happening. All around the composited SVG texture, memory is uninitialized. But this only shows up on tiling GPUs. And only if the driver is doing near-lethal amounts of very legal renderpass optimizations. This fast is too fast.