Vulkan backend (first steps) #983
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
☔ The latest upstream changes (presumably #993) made this pull request unmergeable. Please resolve the merge conflicts. |
…uf creation for the launcher
|
Ok, I merged up and readied the change for merging. It's still from being usable, but is quite a lot of logic already in there - we might as well split it into multiple PRs to avoid the merge hell. Requesting review/merge (after Travis is green, of course). |
|
Let us know if anyone wants to take a deep look into this PR. Otherwise - I'm merging when CI is green. |
|
Wonderful! Fasten your seat belts: |
|
📌 Commit 7e0767b has been approved by |
homu
added a commit
that referenced
this pull request
Aug 12, 2016
Vulkan backend (first steps) Closes #629 This is vastly incomplete, far from a working prototype. I'm getting more and more blocked, so figured it wouldn't harm sharing at least what I got so far: - [x] textures with SRV/RTV/UAV - [x] buffers, no views - [ ] programs with reflection - [x] pipeline states - [x] descriptor layouts/sets - [ ] rendering - [ ] resource updates There is a lot of work left to do, and I expect non-trivial changes to get the proper async rendering. E.g. our command buffer may carry multiple Vulkan command buffers and use them in a ring. Need to track when the GPU finishes using resources too. It doesn't help that `winit` doesn't support XCB (only Xlib), so I had to use xcb-rs directly in the meantime. Currently getting this upon running the cube example: >WARNING: Unsupported SPIR-V Capability ASSERT: Scalar FS validation failed! mov(8) vgrf4+2.0:F, vgrf5+2.0:F ../../../../../../../src/mesa/drivers/dri/i965/brw_fs_validate.cpp:47: inst->dst.reg_offset + inst->regs_written <= alloc.sizes[inst->dst.nr]
|
⚡ Test exempted - status |
adamnemecek
pushed a commit
to adamnemecek/gfx
that referenced
this pull request
Apr 1, 2021
984: Fix locking of device lifetime tracker on resource drop r=kvark a=kvark **Connections** Fixes the player hang in gfx-rs#983 **Description** It turns out the current type-level protection from locking device's lifetime tracker is not working properly. TODO is left. **Testing** Tested on the trace from gfx-rs#983 Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #629
This is vastly incomplete, far from a working prototype. I'm getting more and more blocked, so figured it wouldn't harm sharing at least what I got so far:
There is a lot of work left to do, and I expect non-trivial changes to get the proper async rendering. E.g. our command buffer may carry multiple Vulkan command buffers and use them in a ring. Need to track when the GPU finishes using resources too.
It doesn't help that
winitdoesn't support XCB (only Xlib), so I had to use xcb-rs directly in the meantime.Currently getting this upon running the cube example: