search

gfx-rs / gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
http://gfx-rs.github.io/
Apache License 2.0
5.35k stars 547 forks source link

Clarify TRANSFER_DST semantics with Dynamic usage and updates #1225

Open Bastacyclop opened 7 years ago

Bastacyclop commented 7 years ago

Currently, the Dynamic usage is meant to express update capability and with it the TRANSFER_DST flag is not required but rather implied. Is this what we want, or should we require the flag to be set since updates are transfer operations ? In any case, this behavior should be clarified for the user and we should verify that gfx's code correctly takes it into account: for example the Bind::is_mutable method is currently inaccurate. cc @kvark @eldyer

Bastacyclop commented 7 years ago

I think requiring the TRANSFER_DST flag for Dynamic updates would be more intuitive for both backend implementation and user. To get back some convenience, we could have buffer/texture builders (related to #1036) that would automatically add the TRANSFER_DST flag when specifying a Dynamic usage. @msiglreith It would be nice to start introducing such builders along with corell.

msiglreith commented 7 years ago

In the current iteration, corell exposes heaps with associated properties (https://github.com/gfx-rs/gfx/blob/master/src/corell/src/memory.rs#L38-L63). The exposed heaps depend on backend and adapter (GPU). This should offer the most flexibility for users, who want to deal with the low level API directly.

I would like to move the Dynamic, Data, Upload and Download usage indicators up into render, if possible, and combine them with the proposed builder pattern. The builder searches for the best heap available and also could set some additional flags (e.g TRANSFER_DST for Dynamic).

Bastacyclop commented 7 years ago

@msiglreith sounds good to me :)