|
@@ -42,14 +42,14 @@ Labels will include `kind/bug`, `feature/graphics/mesh`, `sig/graphics-audio`, a
|
|
|
|
|
|
Risks are scored using a risk assessment matrix of impact and likelihood https://en.wikipedia.org/wiki/Risk_matrix
|
|
|
|
|
|
-| Risk | Mitigation | Detection Method | Notes | Impact | Likelihood | Risk Level |
|
|
|
-|---------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------|-------------|------------|----------------|
|
|
|
-| Splitting implementation into two phases will mean that we don't see full scope of impact to other platforms and performance | Consider disabling mesh instancing on platforms not specifically profiled or tested | community feedback that they have a use case that needs instancing on mobile. | Phase 1 initial implementation | negligable | certain | |
|
|
|
-| Mobile performance may be degraded by mesh instancing. Disabled by default and not testing in Phase 1 may only hide any issues | Mesh instancing will be disabled by default, and can be enabled/disabled on a per-project basis. <br>Use profiling to isolate causes of performance impact and seek to address them | We will use deployed test levels on mobile devices to measure frame time impact and draw call count to ensure performance is not impacted. Contract testers will conduct testing | Phase 2 | significant | possible | 14 - medium |
|
|
|
-| iOS may be untestable | we will test only on android if iOS is untestable and accept risk that android and iOS are comparable for impact to performance | existing GHI blocking iOS and contract testers attempting to deploy | Phase 2 | marginal | eliminated | 0 - none |
|
|
|
-| Getting draw call counts may not be possible from RPI when `-rhi=null` which would mean additional work to get it from MeshFeatureProcessor | Worst case we can focus automation on stability when mesh instancing is active. Take the cost of implementing counters in MeshFeatureProcessor | Prototype case review. Exploratory automation | Phase 2 | marginal | unlikely | 2 - negligible |
|
|
|
-| | | | | | | |
|
|
|
-| | | | | | | |
|
|
|
+| Risk | Mitigation | Detection Method | Notes | Impact | Likelihood | Risk Level |
|
|
|
+|---------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------|---------------|-----------------------|----------------|
|
|
|
+| Splitting implementation into two phases will mean that we don't see full scope of impact to other platforms and performance | Mesh instancing will be disabled by default, and can be enabled/disabled on a per-project basis. | community feedback that they have a use case that needs instancing on mobile. | Phase 1 initial implementation | insignificant | certain | 5 - low |
|
|
|
+| Mobile performance may be degraded by mesh instancing. Disabled by default and not testing in Phase 1 may only hide any issues | Mesh instancing will be disabled by default, and can be enabled/disabled on a per-project basis. <br>Use profiling to isolate causes of performance impact and seek to address them | We will use deployed test levels on mobile devices to measure frame time impact and draw call count to ensure performance is not impacted. Contract testers will conduct testing | Phase 2 | significant | possible / eliminated | 14 - medium / 0 - none |
|
|
|
+| iOS may be untestable | we will test only on android if iOS is untestable and accept risk that android and iOS are comparable for impact to performance | existing GHI blocking iOS and contract testers attempting to deploy | Phase 2 | marginal | eliminated | 0 - none |
|
|
|
+| Getting draw call counts may not be possible from RPI when `-rhi=null` which would mean additional work to get it from MeshFeatureProcessor | Worst case we can focus automation on stability when mesh instancing is active. Take the cost of implementing counters in MeshFeatureProcessor | Prototype case review. Exploratory automation | Phase 2 | marginal | unlikely | 2 - negligible |
|
|
|
+| | | | | | | |
|
|
|
+| | | | | | | |
|
|
|
|
|
|
##### **4.1 Assumptions and Dependencies**
|
|
|
|