2008705 - WebGPU: external textures missing on Linux

Status: ASSIGNED

(Core :: Graphics: WebGPU, defect, P1)

Description

[Jamie Nicol [:jnicol]]

This will require:

• a wgpu implementation for external textures on Vulkan/SPV
• Implementing a new function ExternalTextureHostSource::CreateFromDMABufTextureHost() called from here.
  • Which will call in to wgpu_bindings rust code to create a wgpu::Texture from a DMABuf. We should see if this implementation can be shared with the Vulkan swapchain implementation.
• Updating the blocklist here

Comment 1

[Timothy Nikkel (:tnikkel)]

Seems S3 level, please update if incorrect.

Comment 2

[Teodor Tanasoaia [:teoxoy]]

This is a follow-up to a concern I raised in https://phabricator.services.mozilla.com/D324573#inline-1735437.

The Vulkan backend translates wgt::TextureUses::UNINITIALIZED => vk::ImageLayout::UNDEFINED.

Vulkan says:

VUID-VkImageCreateInfo-pNext-01443
If the pNext chain includes a VkExternalMemoryImageCreateInfo or VkExternalMemoryImageCreateInfoNV structure whose handleTypes member is not 0, initialLayout must be VK_IMAGE_LAYOUT_UNDEFINED

from https://docs.vulkan.org/refpages/latest/refpages/source/VkImageCreateInfo.html#VUID-VkImageCreateInfo-pNext-01443

VK_IMAGE_LAYOUT_UNDEFINED specifies that the layout is unknown. Image memory cannot be transitioned into this layout. This layout can be used as the initialLayout member of VkImageCreateInfo. This layout can be used in place of the current image layout in a layout transition, but doing so will cause the contents of the image’s memory to be undefined.

from https://docs.vulkan.org/refpages/latest/refpages/source/VkImageLayout.html#_description

3. Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan- compatible, and those that are Vulkan-incompatible. Vulkan-incompatible APIs will require the image to be in the GENERAL layout whenever they are accessing them.

from https://docs.vulkan.org/refpages/latest/refpages/source/VK_KHR_external_memory.html

Relevant threads:

• https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4686
• https://github.com/ValveSoftware/gamescope/issues/356
• https://gitlab.freedesktop.org/mesa/mesa/-/work_items/6029
• https://gitlab.khronos.org/vulkan/vulkan/-/work_items/3195 (Khronos membership needed)

So I think we need to:

• set initialLayout to ImageLayout::UNDEFINED when creating the image
• set oldLayout to VK_IMAGE_LAYOUT_GENERAL & srcQueueFamilyIndex to VK_QUEUE_FAMILY_FOREIGN_EXT when encoding the first barrier
• check & enable VK_EXT_queue_family_foreign

Comment 3

[Teodor Tanasoaia [:teoxoy]]

I think we should also emit a barrier with dstQueueFamilyIndex set to VK_QUEUE_FAMILY_FOREIGN_EXT and newLayout set to VK_IMAGE_LAYOUT_GENERAL in our zero-readback presentation path. I will open a new bug for this.

Comment 4

[Teodor Tanasoaia [:teoxoy]]

I opened Bug 2074667 for the zero-readback presentation issue. It also includes more references as to why a queue family ownership transfer is needed at all (which also applies to the import path).

Comment 5

[Jim Blandy :jimb]

It seems worth checking how Dawn handled this.

Comment 6

[Andy Leiserson [:aleiserson]]

I have external textures working on Linux on my local dev branches.

• PR or nearly ready for PR:
  • Bug 2081416 - WebGPU: Avoid redundant texture import code / https://phabricator.services.mozilla.com/D333945
  • Import dmabufs via wgpu (Firefox)
  • External texture dmabufs on Linux (Firefox)
  • #10629 Vulkan multi-planar DMA-buf import support
  • #10600 refactor(naga spv-out): Add wrapped function preamble helper
  • vulkan hal external texture binding support (wgpu)
  • SPIR-V external texture support (wgpu)
• Still open:
  • Passing external textures to functions
  • Queue family transfers
  • Compatibility testing

Comment 7

[Andy Leiserson [:aleiserson]]

Deltas from last update in italics.

• PR or nearly ready for PR:
  • Bug 2081416 - WebGPU: Avoid redundant texture import code / https://phabricator.services.mozilla.com/D333945 Landed
  • Import dmabufs via wgpu (Firefox, depends on wgpu#10629)
  • External texture dmabufs on Linux (Firefox)
  • #10629 Vulkan multi-planar DMA-buf import support Awaiting review
  • #10600 refactor(naga spv-out): Add wrapped function preamble helper Awaiting review
  • #10768 feat(vulkan): External texture binding support
  • SPIR-V external texture support (wgpu)
• Still open:
  • Passing external textures to functions
  • Queue family transfers
  • Compatibility testing

Since the last update, I have also worked on cleaning up the SPIR-V external texture support, passing external textures to functions, and on two fixes to multi-planar textures that are import wgpu correctness issues as we expose multi-planar textures more widely, but aren't absolutely required in order to support external textures: #10684 fix(core): Check that clear_texture targets all aspects and #10710 fix(core): Correctly clear multi-planar textures when using render passes

Comment 8

[Andy Leiserson [:aleiserson]]

Deltas from last update in italics.

• PR or nearly ready for PR:
  • Bug 2081416 - WebGPU: Avoid redundant texture import code / https://phabricator.services.mozilla.com/D333945 Landed
  • Import dmabufs via wgpu (Firefox, depends on wgpu#10629)
  • External texture dmabufs on Linux (Firefox)
  • #10629 Vulkan multi-planar DMA-buf import support Awaiting review
  • #10600 refactor(naga spv-out): Add wrapped function preamble helper Awaiting review
  • #10768 feat(vulkan): External texture binding support Landed
  • #10873 Plumbing for external textures in SPIR-V backend
  • SPIR-V image expressions involving external textures
• Still open:
  • Queue family transfers
  • Compatibility testing

Other progress: #10776 Multi-planar texture copy validation