Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task graph [4/10]: compilation #2560

Merged
merged 1 commit into from
Sep 11, 2024
Merged

Task graph [4/10]: compilation #2560

merged 1 commit into from
Sep 11, 2024

Conversation

marc0246
Copy link
Contributor

Follow-up to #2548, implementing the task graph compiler.

I gave up on subresource-granularity sync because it was making everything complicated and I just didn't want to deal with it anymore. The only reason I did it in the first place was because the old sync did it. But that's also what we're trying to replace, so maybe it was just not meant to be. Few things come to mind that couldn't be worked around with whole-resource-granularity sync anyway. A nice side-effect is that this is a whole lot faster both when compiling and executing the task graph.

I converted the async-update example as a very very very (very) early test. Mainly because the kind of syncronization it does was the biggest thorn in my ass.

Changelog:

### Additions
- Added `AccessFlags::{contains_reads,contains_writes}`.

@marc0246 marc0246 force-pushed the taskgraph-4 branch 30 times, most recently from a6196f5 to 18df54e Compare August 29, 2024 03:36
@marc0246 marc0246 force-pushed the taskgraph-4 branch 5 times, most recently from f356acc to 5b4cf1e Compare September 1, 2024 18:54
@marc0246 marc0246 marked this pull request as ready for review September 1, 2024 18:59
@marc0246 marc0246 force-pushed the taskgraph-4 branch 9 times, most recently from 69b5695 to 5b976bf Compare September 3, 2024 05:09
@marc0246 marc0246 force-pushed the taskgraph-4 branch 5 times, most recently from 8027644 to 7c8df6c Compare September 10, 2024 19:15
@Rua
Copy link
Contributor

Rua commented Sep 11, 2024

When I run the async example, I get this validation layer error whenever I press space:

UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x64f9f7847980, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xdd3a8a0000000015, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x64f9f7847980[] expects VkImage 0xdd3a8a0000000015[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL.
Objects: 2
[0] 0x64f9f7847980, type: 6, name: NULL
[1] 0xdd3a8a0000000015, type: 10, name: NULL

Is that ok/still todo?

@marc0246
Copy link
Contributor Author

I'm 99.99% sure that's a hallucination.

@Rua
Copy link
Contributor

Rua commented Sep 11, 2024

I wonder if RenderDoc or such can clarify what's going on. I'll merge it but hopefully we can fix the error at some point, otherwise people are going to report it as a Vulkano bug.

@Rua Rua merged commit 79c30fd into vulkano-rs:master Sep 11, 2024
6 checks passed
@marc0246 marc0246 deleted the taskgraph-4 branch September 11, 2024 13:59
@marc0246
Copy link
Contributor Author

Then you'll be "glad" to learn how many hallucinations I encoutered 😅 while working on this. If it is a hallucination and someone reports it to us, we'll just tell them to go complain to the validation layers. We're not in the business of working around debugging tools. They are supposed to make ours lives easier not harder...

Rua added a commit that referenced this pull request Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants