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
Memory sync test for buffer #302
Memory sync test for buffer #302
Conversation
The first pr for memory sync tests for buffer. I verified the tests in Chromium because currently we have little wgsl code in CTS. It works, which indicate that we can support storage buffer in wgsl(tint) in Chromium. Please take a look at the latest test plan too (We may need to add more binding types, and/or read-after-write, write-after-write, read-before-write combinations). Comments are welcome. |
Please don't review this pr. I have revised it at my local side. I will upload the new one soon. |
Thanks for the heads up. FYI I just reviewed your test plan and I think it looks good, if we can manage to write the code for it. I changed one small thing and added a suggestion for the R-W and W-R tests. |
4b382bd
to
344640e
Compare
Thanks for reviewing the test plan. @kainino0x . This is the first test for write-after-write test. PTAL. Note that I may separate write-after-write into a few tests (for example, copy_and_pass_to pass, and copy_and_pass_to_copy, considering the complexity and the latter will change the destination buffer. Or 4 categories: {copy, pass} x {copy, pass}). The current test is pass to pass. Comments for how to organize the upcoming PRs are also welcome. |
Sorry I still haven't been able to get to this. There is too much to do. :) |
No worries. I suppose the test plan is OK. So I am writing tests for the others at my local side. |
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.
Sorry it's taken me so long to look at this. Added a few comments. @Kangz could you continue to work with Yunchao on the open comments?
Overall I would like to make this cover the complete matrix of pairs of possible reads/writes. Helpers that can do functionally-equivalent reads and writes in every possible way would be complicated but would hopefully make the tests easy to write (and review). It would probably be a helper class, because in a way these tests are stateful (what type of encoder is current) and it should encapsulate that.
Thanks for your review, @Kangz and @kainino0x . It is a little bit late to address all comments because the changes are relatively significant. PTAL. |
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.
Latest changes LGTM. I'm sorry I haven't had time to review the whole thing in a while, I am not currently certain about whether this is implementing the direction we want to take or not.
Maybe tomorrow we can chat on slack (maybe in the morning with @Kangz too?) about what the current state of these tests (this PR + the later ones) is? And also talk about fully general read-op/write-op abstractions that should be generally useful in the test suite.
No problem for me. We can discuss via slack tomorrow morning if needed. What about the time around 9am or 10am? My rough idea is:
|
Thanks for the summary, that will definitely be helpful to discuss. |
Previews, as seen at the time of posting this comment: |
@kainino0x , I added fence for buffer initialization, Please take another look. |
Latest change looks good. Did you have a chance to work on the plan document we talked about for these tests? (If so, I haven't seen it, sorry!) |
Yeah. I am working on that. Will send out it soon. |
@kainino0x , Is this change ready for being merged? What do I need to do if it is not ready? |
I can't rereview this in detail tonight but I don't think it matches the structure in the plan doc. I don't think it will be easier for me to review the changes than to just rereview the tests from scratch once those changes have been made, so I think I'd rather update this PR to match at least the high level structure (file/test/parameterization structure, test descriptions, helpers), rather than landing it and then moving a bunch of code around. |
No problem. I separated the helper functions into a standalone file. I think the vast majority (if not all) of the helper functions can be shared among tests. I noticed your latest comment, are you saying that the helper functions should not be put in a dedicated class for buffer sync test (I named the class as BufferSyncTest though)? The bot failed, but it looks like it is not caused by the test code according to logs? |
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.
Looks much better. I think the idea about a context with various encoders could still prove useful in the future but I don't think we need to block on it.
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
This pull request adds write-after-write tests for buffer sync. The tests write twice (different data) into render pass or compute pass. The second write should overwrite the first one. The tests also consider factors like using bundle or not for render, using the same command buffer or separate command buffers, etc.
It uses new syntax for wgsl, adds writeOps like copy, writeBuffer, map write, etc., and adds tests for separate submits.
Yes, I don't think they need to be part of a fixture; they can just be standalone helper functions that take the GPUDevice as an argument. |
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.
Many small nits but looking good overall!
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
d807fe5
to
1ed1108
Compare
Thanks for your detailed review, Corentin and Kai. I forgot to use |
src/webgpu/api/operation/memory_sync/buffer/write_after_write_in_buffer.spec.ts
Outdated
Show resolved
Hide resolved
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.
np, in this case I just reviewed the two new commits assuming there's nothing new before that.
I cleaned up the "resolved" comment state so every comment that isn't marked as resolved still needs attention. |
All comments were resolved. PTAL @kainino0x |
src/webgpu/api/operation/memory_sync/buffer/buffer_sync_test.ts
Outdated
Show resolved
Hide resolved
LGTM |
This change add memory synchronization tests for buffer in compute.
Each test read the data from a buffer, add 1, and write back to the
buffer and iterate twice in different validation scopes: different
dispatch calls, different passes, or different command buffers. Then
verify the data in buffer.