-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] Rework Vulkan GPUTracker to decorate existing cmd buffers. #46963
[Impeller] Rework Vulkan GPUTracker to decorate existing cmd buffers. #46963
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie or stuartmorgan on the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
I even added ... well, its sort of a test. |
|
|
||
| auto status = command_buffer.end(); | ||
| if (status != vk::Result::eSuccess) { | ||
| gpu_tracer_->OnFenceComplete(end_frame); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here and below, should we somehow signal to the tracer that it's ending really fast because of a failure?
I'm assuming here we'd get a zero duration, do we want something like a -1 duration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. If we encounter an error we should not report for the frame since its probably an all bets are off situation.
| #include "impeller/renderer/backend/vulkan/command_encoder_vk.h" | ||
| #include "impeller/renderer/backend/vulkan/context_vk.h" | ||
| #include "impeller/renderer/command_buffer.h" | ||
| #include "vulkan/vulkan_enums.hpp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this right? Should this just be vulkan/vulkan.hpp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get "included header is not used"
|
The previous implementation regressed raster time due to the addition of more cmd buffer submissions: We should make sure this fixes that. |
matanlurey
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved.
I'd file a follow-up issue for any comments/tests that are worth adding after this sticks.
| } | ||
|
|
||
| void GPUTracerVK::RecordStartFrameTime() { | ||
| bool GPUTracerVK::IsValid() const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just being pedantic, IsValid feels weird given it's totally valid for this instance to exist in an invalid state (i.e. either timestamp_period not being supported, or debug mode being disabled).
Consider renaming this IsEnabled() and consider making it private since there isn't (AFAICT) a reason for another class to check this property, it's internal-only state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more or less just for testing. Update to IsEnabled SGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| } | ||
|
|
||
| void GPUTracerVK::MarkFrameStart() { | ||
| in_frame_ = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth adding a FML_DCHECK that a frame is never started when in_frame_ already is true?
(Maybe that's fine given what you told me offline about multiple frames running concurrently - if so a 1-line comment documenting that would be nice to have)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, and added more comments to the in_frame_ field
| current_state_ = (current_state_ + 1) % 16; | ||
|
|
||
| auto& state = trace_states_[current_state_]; | ||
| FML_DCHECK(state.pending_buffers == 0u); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can you add a << "Reason why bad" sort of self-documenting why this should be 0?
It's confusing because the next line sets it to 0, why set it to 0 if it's already 0 :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| // We size the query pool to kPoolSize, but Flutter applications can create an | ||
| // unbounded amount of work per frame. If we encounter this, stop recording | ||
| // cmds. | ||
| if (state.current_index >= kPoolSize) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you expect this to be common?
I wonder if it makes sense to at least log that recording did not happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think this would be extremely rare but adapting the tracer to work with arbitrarily resizing query pools is much harder so punting for now.
| void GPUTracerVK::RecordEndFrameTime() { | ||
| if (!valid_ || !started_frame_) { | ||
| void GPUTracerVK::RecordCmdBufferStart(const vk::CommandBuffer& buffer) { | ||
| if (!valid_ || !in_frame_) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the !in_frame_ guard related to multiple concurrent frames?
If so can we add that as a 1-line comment. If not should it be DCHECK'd instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added more explaination to what in_frame_ does
| } | ||
|
|
||
| size_t GPUTracerVK::RecordCmdBufferEnd(const vk::CommandBuffer& buffer) { | ||
| if (!valid_ || !in_frame_) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Ditto above, though if no action is needed then disregard)
| state.contains_failure = !success; | ||
| state.pending_buffers -= 1; | ||
|
|
||
| if (state.pending_buffers == 0 && !state.contains_failure) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explain in 1-line what you told me offline re: filtering out failures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added more comment to contains_failure field on trace state.
| static_cast<VkSampleCountFlags>(VK_SAMPLE_COUNT_1_BIT | | ||
| VK_SAMPLE_COUNT_4_BIT); | ||
| pProperties->limits.maxImageDimension2D = 4096; | ||
| pProperties->limits.timestampPeriod = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Just a comment)
We could make this configurable if you want to ensure timestampPeriod of 0 doesn't crash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned offline, I think given we're not sure this will stay landed (performance reasons, or otherwise), more tests aren't needed at this point as long as it "works on my machine". However I'd add a TODO for at least the following unit tests if this stays landed:
These are just suggestions, feel free to tweak wording
- Success case where a frame is captured
- Success case where MAX_FRAMES are captured
- Success case where > MAX_FRAMES are captured and it wraps around (?)
- Assert query pool is only initialized on the first frame
- Failure case for unbounded amount of frames
- Assert that contains_failure captures are dropped
- Assert that your logic for longest frame WAI (i.e. multiple concurrent frames captures the right values)
Also should be asserting the final call to FML_TRACE_COUNTEr is actually recording the expected value.
|
Fixed an issue where we could partially record the mipmap cmd buffers. We now record the raster thread id and only permit cmd buffers recorded from the raster thread (in additon to the thread boundary checks). |
|
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. |
…136774) flutter/engine@5df7af3...2eef9b4 2023-10-17 [email protected] Move imgui from buildroot to flutter third_party (flutter/engine#47031) 2023-10-17 [email protected] [Impeller] Rework Vulkan GPUTracker to decorate existing cmd buffers. (flutter/engine#46963) 2023-10-17 [email protected] [fml][embedder] Improve thread-check logging (flutter/engine#47020) 2023-10-17 [email protected] Roll Dart SDK from 99ce477503f8 to da48c75b73b1 (1 revision) (flutter/engine#47027) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC [email protected],[email protected],[email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…#46963) Switches the GPU tracing implementation to work more like the metal version, where we decorate individual cmd buffers with start/end time queries and then min/max the final result. Hopefully this stabilizes the values on CI
Switches the GPU tracing implementation to work more like the metal version, where we decorate individual cmd buffers with start/end time queries and then min/max the final result. Hopefully this stabilizes the values on CI