Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@jonahwilliams
Copy link
Contributor

@jonahwilliams jonahwilliams commented Oct 16, 2023

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

@flutter-dashboard
Copy link

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.

@jonahwilliams jonahwilliams changed the title [Impeller] Make Vulkan tracing not crashy. [Impeller] Rework Vulkan GPUTracker to decorate existing cmd buffers. Oct 16, 2023
@jonahwilliams jonahwilliams requested a review from dnfield October 16, 2023 20:37
@jonahwilliams
Copy link
Contributor Author

I even added ... well, its sort of a test.


auto status = command_buffer.end();
if (status != vk::Result::eSuccess) {
gpu_tracer_->OnFenceComplete(end_frame);
Copy link
Contributor

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?

Copy link
Contributor Author

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"
Copy link
Contributor

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?

Copy link
Contributor Author

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"

Copy link
Contributor

@matanlurey matanlurey left a 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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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;
Copy link
Contributor

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)

Copy link
Contributor Author

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);
Copy link
Contributor

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

Copy link
Contributor Author

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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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_) {
Copy link
Contributor

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?

Copy link
Contributor Author

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_) {
Copy link
Contributor

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) {
Copy link
Contributor

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

Copy link
Contributor Author

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;
Copy link
Contributor

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.

Copy link
Contributor

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

  1. Success case where a frame is captured
  2. Success case where MAX_FRAMES are captured
  3. Success case where > MAX_FRAMES are captured and it wraps around (?)
  4. Assert query pool is only initialized on the first frame
  5. Failure case for unbounded amount of frames
  6. Assert that contains_failure captures are dropped
  7. 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.

@jonahwilliams
Copy link
Contributor Author

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).

@flutter-dashboard
Copy link

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.

Changes reported for pull request #46963 at sha 8394706

@jonahwilliams jonahwilliams added the autosubmit Merge PR when tree becomes green via auto submit App label Oct 17, 2023
@auto-submit auto-submit bot merged commit 910a7cb into flutter:main Oct 17, 2023
@jonahwilliams jonahwilliams deleted the make_vulkan_tracing_not_crashy branch October 17, 2023 22:54
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Oct 18, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Oct 18, 2023
…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
harryterkelsen pushed a commit that referenced this pull request Oct 23, 2023
…#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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

autosubmit Merge PR when tree becomes green via auto submit App e: impeller will affect goldens

Projects

No open projects
Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants