Sparse (tiled) resources for Vulkan and DirectX 12

[deprilula28]

Progress in implementing sparse resources, listed on issue #1610

This PR adds the following:

• A bind_sparse method in CommandQueue based on submit.
• A Vulkan implementation for bind_sparse, making a vkQueueBindSparse call.
• A DirectX12 implementation for bind_sparse for images, creating a virtual resource with CreateReservedResource if unbound and mapping it to memory with UpdateTileMappings.
• SPARSE_BINDING, SPARSE_RESIDENCY and SPARSE_ALIASED view capabilities when creating images. Also sets the texture layout to D3D12_TEXTURE_LAYOUT_64KB_UNDEFINED_SWIZZLE when creating images on DX12.
• A sparselybound feature on the quad example which binds the logo texture using bind_sparse instead of bind_image_memory.

Remaining additions:

• [ ] DirectX 11 implementation.
• [ ] Buffer and opaque textures in the DirectX 12 implementation.
• [ ] Setting sparse flags in buffer resources. (This will have to be a breaking change or a different buffer create method)

PR checklist:

• [x] make succeeds (on *nix)
• [x] make reftests succeeds
• [x] tested examples with the following backends: Vulkan, DirectX 12, DirectX 11

[deprilula28]

I've been looking until now and have no idea why metal is failing. If someone can review that for me I would be grateful.

[kvark]

You can grab https://github.com/kvark/gfx/commit/9f37e23ec118f38d8cf4f777c3c35634b5d10ae2 for the metal fix Please squash everything when ready.

[kvark]

Please address the concern about sparselybound feature (i.e. remove the feature), and squash the changes to proceed.

[deprilula28]

I think I did that right, I'm sorry I'm not that experienced with doing PRs

[kvark]

@deprilula28

This branch cannot be rebased due to conflicts

Also, please squash the commits after rebase!

[kvark]

Given that this is very advanced, I'm also wondering if some of the methods should just have a default implementation that is unimplemented!(). This would say quite some boilerplate in the backends.

[Neo-Zhixing]

What is the status on this PR? Is this still moving forward?

[deprilula28]

I've been busy and forgot about this, but there shouldn't be that much left

[kvark]

@deprilula28 we've done a massive API simplification pass when releasing 0.7, and this PR needs to be updated accordingly. There is no Borrow or IntoIterator in the API any more.

[deprilula28]

Are those the only changed needed?

[kvark]

Yeah, I think the other question I had if it would be nicer to have the default implementations for the new methods, since they aren't implemented for most backends yet, anyway. But that's not something I feel strongly about - basically implementors (yours) choice here. And a rebase, of course:)

[deprilula28]

I have removed the goal for an OpenGL implementation as the extension is rarely supported and doesn't exist on WebGL

[deprilula28]

@kvark I'm not sure this is how you would rather I do it, it does break the API for create_buffer

[deprilula28]

I have absolutely no idea what happened I didn't touch .gitignore lol

[kvark]

This branch cannot be rebased due to conflicts

[deprilula28]

How do I get to see the conflicts?

[kvark]

I recommend first squashing everything into one commit, then doing git pull -r upstream master, where "upstream" is associated with this remote.

[Neo-Zhixing]

@deprilula28 You don't get to see the conflicts because you're trying to merge. Git rebase works a bit differently and if you rebase to master it'll ask you to resolve all the conflicts again. Here's an easier way to do this:

Assuming your working copy is clean:

git merge upstream/master
git reset upstream/master
git add *
git commit

I've tested, this should give you a single beautifully squashed commit attached to upstream/master.

Thank you for your work!

[bors[bot]]

Build succeeded:

• Android Stable
• Dependency Check
• iOS Stable
• MacOS Nightly
• MacOS Stable
• Ubuntu Nightly
• Ubuntu Stable
• Web Assembly
• Windows Nightly
• Windows Stable