Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Timestamp Queries to Bitonic Sort Example #347

Merged
merged 12 commits into from
Jan 20, 2024

Conversation

cmhhelgeson
Copy link
Contributor

Utilized example code found at https://developer.chrome.com/blog/new-in-webgpu-121 to add timestamp queries for the bitonic sort on compatible browsers.

At large enough element sizes, these queries can be used to compare the performance between sorts of various sizes, or compare performance when the maximum invocations per dispatch are arbitrarily limited.

Minor changes:
'Complete Sort' has been renamed to 'Auto Sort' to better reflect controller functionality.

let querySet: GPUQuerySet;
let timestampQueryResolveBuffer: GPUBuffer;
let timestampQueryResultBuffer: GPUBuffer;
console.log(timestampQueryAvailable);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
console.log(timestampQueryAvailable);

prefer not to log things automatically

// MISCELLANEOUS SETTINGS
'Display Mode': 'Elements',
// An atomic value representing the total number of swap operations executed over the course of the bitonic sort.
'Total Swaps': 0,
// Time taken to sort in seconds (not nanoseconds!). If timestep query feature is not available then this will remain 0.
'Sort Time': '0s',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not display it in.. milliseconds? right now the seconds are hard to read. For me it sometimes says things like "0.000065536s"

Copy link
Collaborator

@austinEng austinEng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

observation: it's interesting that on my machine, the first sort step takes 0.06ms and the last one takes 2ms

@cmhhelgeson
Copy link
Contributor Author

cmhhelgeson commented Jan 19, 2024

observation: it's interesting that on my machine, the first sort step takes 0.06ms and the last one takes 2ms

It's probably not clear from the provided code yet, but the displayed time is accumulating the times of each step rather than displaying the time a single step takes to execute. Given that the last step is almost certainly swapping over global indices rather than workgroup local indices at greater than 512 elements, it stands to reason that the last step would take longer than the first step, but I don't believe there should be such a large disparity in time. Perhaps there should be a display controller that displays the time a single step takes to execute (i.e if you're using Execute Sort Step rather than Auto Sort), a display controller that accumulates the times for each step within a sort, and maybe a final display controller that averages out the time a sort takes under a certain sort config combination (Elements + Workgroup Size Limit)

@cmhhelgeson
Copy link
Contributor Author

I think I'll fix/add that (maybe move this back to draft or ask for re-review later).

… sort time for a full bitonic sort given the current configuration of Total Elements and Size Limit
@cmhhelgeson
Copy link
Contributor Author

cmhhelgeson commented Jan 19, 2024

I think I'll fix/add that (maybe move this back to draft or ask for re-review later).

@austinEng This should be finished now bar any unexpected bugs.

@cmhhelgeson cmhhelgeson requested a review from austinEng January 19, 2024 22:43
@austinEng austinEng merged commit f4b46f0 into webgpu:main Jan 20, 2024
1 check passed
@cmhhelgeson cmhhelgeson deleted the bitonic_timestamp_update branch February 28, 2024 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants