Remove SubMesh type #281
Merged
Remove SubMesh type #281
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
This currently is not used for anything
fkaa
added a commit
to fkaa/gfx
that referenced
this pull request
Jun 14, 2018
Fixes previous `Memory` implementation. Now works like the following:
```
0.........................size
+----------------------------+
| Memory |
+----------------------------+
A..B C.....D E...F
1 fixed-size `STAGING` buffer which gets used for reading back from
resources.(and should be used to copy from/to on flush/invalidate):
(0..size, ComPtr<Buffer>)
1 `Vec<u8>` which covers the whole memory range (0..size). This is
pointer we hand out to users. flush/invalidate moves the affected
regions into our `STAGING` buffer to get read/uploaded.
*N* Resources:
(A..B, ComPtr<Resource>),
(C..D, ComPtr<Resource>),
(E..F, ComPtr<Resource>),
```
Implements copying between images and buffers. Image<->Image copies are
mostly handled by `CopySubresourceRegion` but some formats, while same
size, cant be copied with this method:
> Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR gfx-rs#281: ]
These has to be done through compute shaders instead. Image->Buffer &
Buffer->Image copies also have to be done through compute shaders, as
`CopySubresourceRegion` can only copy between resources of same type
(Image<->Image, Buffer<->Buffer). The following formats have
Buffer->Image and Image->Buffer copies implemented with these changes:
* `R8`
* `Rg8`
* `R16`
* `Rg16`
* `R32`
3 tasks
fkaa
added a commit
to fkaa/gfx
that referenced
this pull request
Jun 21, 2018
Fixes previous `Memory` implementation. Now works like the following:
```
0.........................size
+----------------------------+
| Memory |
+----------------------------+
A..B C.....D E...F
1 fixed-size `STAGING` buffer which gets used for reading back from
resources.(and should be used to copy from/to on flush/invalidate):
(0..size, ComPtr<Buffer>)
1 `Vec<u8>` which covers the whole memory range (0..size). This is
pointer we hand out to users. flush/invalidate moves the affected
regions into our `STAGING` buffer to get read/uploaded.
*N* Resources:
(A..B, ComPtr<Resource>),
(C..D, ComPtr<Resource>),
(E..F, ComPtr<Resource>),
```
Implements copying between images and buffers. Image<->Image copies are
mostly handled by `CopySubresourceRegion` but some formats, while same
size, cant be copied with this method:
> Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR gfx-rs#281: ]
These has to be done through compute shaders instead. Image->Buffer &
Buffer->Image copies also have to be done through compute shaders, as
`CopySubresourceRegion` can only copy between resources of same type
(Image<->Image, Buffer<->Buffer). The following formats have
Buffer->Image and Image->Buffer copies implemented with these changes:
* `R8`
* `Rg8`
* `R16`
* `Rg16`
* `R32`
fkaa
added a commit
to fkaa/gfx
that referenced
this pull request
Jun 21, 2018
Fixes previous `Memory` implementation. Now works like the following:
```
0.........................size
+----------------------------+
| Memory |
+----------------------------+
A..B C.....D E...F
1 fixed-size `STAGING` buffer which gets used for reading back from
resources.(and should be used to copy from/to on flush/invalidate):
(0..size, ComPtr<Buffer>)
1 `Vec<u8>` which covers the whole memory range (0..size). This is
pointer we hand out to users. flush/invalidate moves the affected
regions into our `STAGING` buffer to get read/uploaded.
*N* Resources:
(A..B, ComPtr<Resource>),
(C..D, ComPtr<Resource>),
(E..F, ComPtr<Resource>),
```
Implements copying between images and buffers. Image<->Image copies are
mostly handled by `CopySubresourceRegion` but some formats, while same
size, cant be copied with this method:
> Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR gfx-rs#281: ]
These has to be done through compute shaders instead. Image->Buffer &
Buffer->Image copies also have to be done through compute shaders, as
`CopySubresourceRegion` can only copy between resources of same type
(Image<->Image, Buffer<->Buffer). The following formats have
Buffer->Image and Image->Buffer copies implemented with these changes:
* `R8`
* `Rg8`
* `R16`
* `Rg16`
* `R32`
fkaa
added a commit
to fkaa/gfx
that referenced
this pull request
Jun 21, 2018
Fixes previous `Memory` implementation. Now works like the following:
```
0.........................size
+----------------------------+
| Memory |
+----------------------------+
A..B C.....D E...F
1 fixed-size `STAGING` buffer which gets used for reading back from
resources.(and should be used to copy from/to on flush/invalidate):
(0..size, ComPtr<Buffer>)
1 `Vec<u8>` which covers the whole memory range (0..size). This is
pointer we hand out to users. flush/invalidate moves the affected
regions into our `STAGING` buffer to get read/uploaded.
*N* Resources:
(A..B, ComPtr<Resource>),
(C..D, ComPtr<Resource>),
(E..F, ComPtr<Resource>),
```
Implements copying between images and buffers. Image<->Image copies are
mostly handled by `CopySubresourceRegion` but some formats, while same
size, cant be copied with this method:
> Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR gfx-rs#281: ]
These has to be done through compute shaders instead. Image->Buffer &
Buffer->Image copies also have to be done through compute shaders, as
`CopySubresourceRegion` can only copy between resources of same type
(Image<->Image, Buffer<->Buffer). The following formats have
Buffer->Image and Image->Buffer copies implemented with these changes:
* `R8`
* `Rg8`
* `R16`
* `Rg16`
* `R32`
fkaa
added a commit
to fkaa/gfx
that referenced
this pull request
Jun 22, 2018
Fixes previous `Memory` implementation. Now works like the following:
```
0.........................size
+----------------------------+
| Memory |
+----------------------------+
A..B C.....D E...F
1 fixed-size `STAGING` buffer which gets used for reading back from
resources.(and should be used to copy from/to on flush/invalidate):
(0..size, ComPtr<Buffer>)
1 `Vec<u8>` which covers the whole memory range (0..size). This is
pointer we hand out to users. flush/invalidate moves the affected
regions into our `STAGING` buffer to get read/uploaded.
*N* Resources:
(A..B, ComPtr<Resource>),
(C..D, ComPtr<Resource>),
(E..F, ComPtr<Resource>),
```
Implements copying between images and buffers. Image<->Image copies are
mostly handled by `CopySubresourceRegion` but some formats, while same
size, cant be copied with this method:
> Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR gfx-rs#281: ]
These has to be done through compute shaders instead. Image->Buffer &
Buffer->Image copies also have to be done through compute shaders, as
`CopySubresourceRegion` can only copy between resources of same type
(Image<->Image, Buffer<->Buffer). The following formats have
Buffer->Image and Image->Buffer copies implemented with these changes:
* `R8`
* `Rg8`
* `R16`
* `Rg16`
* `R32`
bors bot
added a commit
that referenced
this pull request
Jun 23, 2018
2071: Remaping descriptor sets in the gl backend r=kvark a=ZeGentzy I'll rebase off master when I'm done. Uniforms in gl only have a bindings field, not a set one. This means that for shaders that use multiple sets to work, we must change where we are binding them. See page 14 for what I mean: https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devday-uk/4-Using-spir-v-with-spirv-cross.pdf PR checklist: - [ ] `make` succeeds (on *nix) - [ ] `make reftests` succeeds - [ ] tested examples with the following backends: 2149: [dx11] add memory flush/invalidate & image/buffer copies r=kvark a=fkaa Main changes are adding more robust implementation of `Memory`, adding flush/invalidate and adding image/buffer copies. Implements `Memory` like the following (for `HOST_VISIBLE` memory): ``` 0.........................size +----------------------------+ | Memory | +----------------------------+ A..B C.....D E...F 1 fixed-size `STAGING` buffer which gets used for reading back from resources.(and should be used to copy from/to on flush/invalidate): (0..size, ComPtr<Buffer>) 1 `Vec<u8>` which covers the whole memory range (0..size). This is pointer we hand out to users. flush/invalidate moves the affected regions into our `STAGING` buffer to get read/uploaded. *N* Resources: (A..B, ComPtr<Resource>), (C..D, ComPtr<Resource>), (E..F, ComPtr<Resource>), ``` Implements copying between images and buffers. Image<->Image copies are mostly handled by `CopySubresourceRegion` but some formats, while same size, cant be copied with this method: > Cannot invoke CopySubresourceRegion when the Formats of each Resource are not the same or at least castable to each other, unless one format is compressed (DXGI_FORMAT_R9G9B9E5_SHAREDEXP, or DXGI_FORMAT_BC[1,2,3,4,5]_* ) and the source format is similar to the dest according to: BC[1|4] ~= R16G16B16A16|R32G32, BC[2|3|5] ~= R32G32B32A32, R9G9B9E5_SHAREDEXP ~= R32. [ RESOURCE_MANIPULATION ERROR #281: ] These has to be done through compute shaders instead. Image->Buffer & Buffer->Image copies also have to be done through compute shaders, as `CopySubresourceRegion` can only copy between resources of same type (Image<->Image, Buffer<->Buffer). The following formats have Buffer->Image and Image->Buffer copies implemented with these changes: * `R8` * `Rg8` * `R16` * `Rg16` * `R32` Gets about 400 tests passed and equal amount failed in `dEQP-VK.api.copy_and_blit.core.image_to_image.all_formats.color` (mostly because `CopySubresourceRegion` failing to copy between some formats as mentioned above) Fixes #issue PR checklist: - [ ] `make` succeeds (on *nix) - [ ] `make reftests` succeeds - [ ] tested examples with the following backends: 2154: hal: Improve buffer documentation and cleanup error handling r=kvark a=msiglreith Fixes #issue PR checklist: - [ ] `make` succeeds (on *nix) - [ ] `make reftests` succeeds - [ ] tested examples with the following backends: Co-authored-by: Hal Gentz <[email protected]> Co-authored-by: Felix Kaaman <[email protected]> Co-authored-by: msiglreith <[email protected]>
adamnemecek
pushed a commit
to adamnemecek/gfx
that referenced
this pull request
Apr 1, 2021
281: Force pipeline barriers between unordered usages r=grovesNL a=kvark Fixes gfx-rs#272 Co-authored-by: Dzmitry Malyshau <[email protected]>
adamnemecek
pushed a commit
to adamnemecek/gfx
that referenced
this pull request
Apr 1, 2021
302: Fixed pipeline barriers that are not transitions r=grovesNL a=kvark The actual fix is a one-liner: `u.start != u.end` bit in `PendingTransition::record`. The case is relatively new - as of gfx-rs#281, which I haven't tested extensively. The PR also improves our logging for further assistance with similar issues... but the most annoying piece is that I would find this much much earlier if I didn't ignore the result here: `let _ = state.change(...)`. Let it be the lesson to all of us :) Co-authored-by: Dzmitry Malyshau <[email protected]>
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.
This currently is not used for anything