You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to establish a way for applications to fine-tune the backends up to their needs. In Metal, I can at least think of the following parameters:
maximum number of active command buffers
support for immediately recorded command buffers
auto-enqueuing of command buffers
These are not required for anybody to touch, but resource demanding applications could benefit for a few knobs to play with in order to assist the performance. E.g. while in general immediate recording is great, with Dota it is actually slower due to rare submissions... see #2232 for more info.
On clear thing we could establish here is some sort of configuration API, maybe even a public struct field, on the Instance or PhysicalDevice (specific to backends). Another possible route is via environment variables, e.g. GFX_METAL_IMMEDIATE_RECORDING=0 make quad. I believe the latter is only needed for applications going through gfx-portability, so we might as well just put the envar handling in there.
The text was updated successfully, but these errors were encountered:
I suppose another possibility is a gfx extension to Vulkan, so we don't have to commit to any particular configuration API/environment variables on the HAL side (at least depending on what happens with #2206)
@grovesNL indeed, but this would be quite painful:
extensions need to be published and set in stone, while our flags may be more fluent, and the target user (who is shipping an application with gfx-rs always knows the exact set of flags).
our flags are vastly different between backends, so we'd have to have an extension per backend
2292: Metal command recording option r=grovesNL a=kvark
Based on #2288
Implements first bits of #2236
Allows the client to control the recording option without re-building gfx-rs.
Also hides the remote sink behind a feature. We can't CI-test it until SSheldon/rust-dispatch#10 is accepted and published.
PR checklist:
- [ ] `make` succeeds (on *nix)
- [ ] `make reftests` succeeds
- [ ] tested examples with the following backends:
- [ ] `rustfmt` run on changed code
Co-authored-by: Dzmitry Malyshau <[email protected]>
borsbot
added a commit
that referenced
this issue
Aug 4, 2018
2292: Metal command recording option r=grovesNL a=kvark
Based on #2288
Implements first bits of #2236
Allows the client to control the recording option without re-building gfx-rs.
Also hides the remote sink behind a feature. We can't CI-test it until SSheldon/rust-dispatch#10 is accepted and published.
PR checklist:
- [ ] `make` succeeds (on *nix)
- [ ] `make reftests` succeeds
- [ ] tested examples with the following backends:
- [ ] `rustfmt` run on changed code
Co-authored-by: Dzmitry Malyshau <[email protected]>
We need to establish a way for applications to fine-tune the backends up to their needs. In Metal, I can at least think of the following parameters:
These are not required for anybody to touch, but resource demanding applications could benefit for a few knobs to play with in order to assist the performance. E.g. while in general immediate recording is great, with Dota it is actually slower due to rare submissions... see #2232 for more info.
On clear thing we could establish here is some sort of configuration API, maybe even a public struct field, on the
Instance
orPhysicalDevice
(specific to backends). Another possible route is via environment variables, e.g.GFX_METAL_IMMEDIATE_RECORDING=0 make quad
. I believe the latter is only needed for applications going through gfx-portability, so we might as well just put the envar handling in there.The text was updated successfully, but these errors were encountered: