Skip to content

Allow RENDER_ATTACHMENT on multi planar texture formats #8205

@noituri

Description

@noituri

Is your feature request related to a problem? Please describe.
We're trying to render onto NV12 texture. WGPU during texture creation checks if given format supports the provided usages. Since NV12 itself does not support RENDER_ATTACHMENT wgpu won't allow creating such texture.

While NV12 can't be used directly as color attachment, on vulkan (not sure about DX12) you can create VK_FORMAT_R8_UNORM and VK_FORMAT_R8G8_UNORM views and render onto them. This requires creating image with MUTABLE_FORMAT and EXTENDED_USAGE flags.

Technically it's currently possible with wgpu::hal::vulkan::Device::texture_from_raw which adds EXTENDED_USAGE, but the views created from that texture can't create valid render_extent.

For example, for NV12 texture view with format VK_FORMAT_R8G8_UNORM and aspect TextureAspect::Plane1 we should expect its width and height to be divided by 2 instead of having the full texture extent.
Also the view does not allow the aspects of texture view to be a subset of the aspects in the original texture, which means I can't create renderable view for just plane0.
I'm not entirely sure why this check exists. I would appreciate some input on this.

Describe the solution you'd like

  • It should be possible to create renderable views for aspects that are subset of the original texture.
  • Views of multi planar textures should have correct render_extent.
  • Ideally there should be a way of creating multi planar textures with RENDER_ATTACHMENT and EXTENDED_USAGE without using hal.

I'm not entirely sure how hard would it be to add proper support for this in WGPU but I'd be willing to work on this with some guidance.

Describe alternatives you've considered
Currently we're using vulkan hal and calling vulkan directly.

We'd be fine with this approach but we're also binding wgpu RGBA texture and sampling from it which forces us to use CommandEncoder::transition_resources to transition the sampled texture into RESOURCE. We've noticed that if you use one command buffer to transition_resources and then run hal vulkan pipeline, vulkan is not aware of the transition.
We had to transition the texture -> submit command buffer -> record hal vulkan render pass -> submit another command buffer. We would prefer to avoid this extra submit in between.

We did try the mentioned wgpu::hal::vulkan::Device::texture_from_raw but view render_extent is not valid.

Additional context
I have no experience with DX12 so I'm not sure what changes would be required here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions