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

Memory sync test for buffer #302

Merged
merged 11 commits into from Nov 21, 2020

Conversation

Richard-Yunchao
Copy link
Contributor

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.

@Richard-Yunchao
Copy link
Contributor Author

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.

@Richard-Yunchao
Copy link
Contributor Author

Please don't review this pr. I have revised it at my local side. I will upload the new one soon.

@kainino0x
Copy link
Collaborator

kainino0x commented Oct 6, 2020

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.

@Richard-Yunchao
Copy link
Contributor Author

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.

@kainino0x
Copy link
Collaborator

Sorry I still haven't been able to get to this. There is too much to do. :)

@Richard-Yunchao
Copy link
Contributor Author

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.

src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
Copy link
Collaborator

@kainino0x kainino0x left a 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.

src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
src/webgpu/api/operation/memory_sync/buffer.spec.ts Outdated Show resolved Hide resolved
@Richard-Yunchao
Copy link
Contributor Author

Thanks for your review, @Kangz and @kainino0x . It is a little bit late to address all comments because the changes are relatively significant. PTAL.

Copy link
Collaborator

@kainino0x kainino0x left a 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.

@Richard-Yunchao
Copy link
Contributor Author

Richard-Yunchao commented Oct 23, 2020

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:

  • Put all helper functions, for example, createBuffer, createBindGroup, writeByRenderPass, etc., in a separate file. And write tests in write-after-write-in-buffer.spec.ts, read-after-write-in-buffer.spec.ts, and read-before-write-in-buffer.spec.ts.
  • In each test, it might has a couple of comprehensive tests of combined parameters to cover most cases, while a few separated tests to cover some special cases. Take write-after-write as an example, the comprehensive test is the current one we are reviewing (write-after-write), but we need to test two writes in the same render or compute pass. The latter tests are not easy to be combined into the current test, and the expected result of render pass (two writes in the same render pass) should have loose guarantees.

@kainino0x
Copy link
Collaborator

Thanks for the summary, that will definitely be helpful to discuss.

@github-actions
Copy link

Previews, as seen at the time of posting this comment:
Run this PR's tests live
0baf2e5

@Richard-Yunchao
Copy link
Contributor Author

@kainino0x , I added fence for buffer initialization, Please take another look.

@kainino0x
Copy link
Collaborator

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

@Richard-Yunchao
Copy link
Contributor Author

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.

@Richard-Yunchao
Copy link
Contributor Author

@kainino0x , Is this change ready for being merged? What do I need to do if it is not ready?

@kainino0x
Copy link
Collaborator

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

@Richard-Yunchao
Copy link
Contributor Author

@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?

Copy link
Collaborator

@Kangz Kangz left a 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.

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.
@kainino0x
Copy link
Collaborator

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

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.

Copy link
Collaborator

@kainino0x kainino0x left a 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!

@Richard-Yunchao
Copy link
Contributor Author

Thanks for your detailed review, Corentin and Kai. I forgot to use git merge but rebased the code in the middle in order to fix a build error after I updated my local main branch. Sorry for that. It might be inconvenient for you to review.

Copy link
Collaborator

@kainino0x kainino0x left a 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.

@kainino0x
Copy link
Collaborator

I cleaned up the "resolved" comment state so every comment that isn't marked as resolved still needs attention.

@Richard-Yunchao
Copy link
Contributor Author

All comments were resolved. PTAL @kainino0x

@kainino0x
Copy link
Collaborator

LGTM

@kainino0x kainino0x merged commit 6107b35 into gpuweb:main Nov 21, 2020
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.

None yet

3 participants