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

Compat: Add tests for maxStorage(Buffer/Texture)sIn(Vertex/Fragment)Stage #4118

Merged
merged 2 commits into from
Jan 6, 2025

Conversation

greggman
Copy link
Contributor

Note: I couldn't really think of a test on the core side. Originally I was going to try to request maxXXXInYYYStage less than maxXXXPerShaderStage which is what the tests do in compat but in core I believe it will be a no-op and that InStage limits will always match their PerStage counterparts.

I added a RequiredLimitsTestMixin to try to make it easier to write a test that needs specific limits. The issue is the key. I thought about making the key just be the source of getRequiredLimits but I can imagine someone writing some more generic requester that takes a list of of limits in which case the code would be generic and so using the source of the function would not be a valid key.

I also thought about adding a MaxOfSpecificLimitsMixin where you could pass in a list of maxes but I think most code that needs maxes can use MaxLimitsTestMixin


Requirements for PR author:

  • All missing test coverage is tracked with "TODO" or .unimplemented().
  • New helpers are /** documented */ and new helper files are found in helper_index.txt.
  • Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
  • Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

  • Tests are properly located in the test tree.
  • Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
  • Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
  • Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

@greggman greggman requested a review from kainino0x December 27, 2024 00:23
@greggman greggman force-pushed the test-maxSTB branch 2 times, most recently from d2a2b28 to 6ac0f62 Compare December 31, 2024 00:54
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.

The key thing makes sense, I don't have a better suggestion. LGTM

t.skipIf(inStageLimit === 0, `${limit} is 0`);
t.skipIf(
!(inStageLimit < perStageLimit),
`{${limit}(${inStageLimit}) is not less than ${perStageLimitName}(${perStageLimit}})`
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: same here

…tage

Note: I couldn't really think of a test on the core side.
Originally I was going to try to request `maxXXXInYYYStage` less
than `maxXXXPerShaderStage` which is what the tests do in compat
but in core I believe it will be a no-op and that InStage limits
will always match their PerStage counterparts.

I added a `RequiredLimitsTestMixin` to try to make it easier to
write a test that needs specific limits. The issue is the key.
I thought about making the key just be the source of `getRequiredLimits`
but I can imagine someone writing some more generic requester
that takes a list of of limits in which case the code would be generic
and so using the source of the funciton would not be a valid key.

I also though about adding a MaxOfSpecificLimitsMixin where you could
pass in a list of maxes but I think most code that needs maxes can use
MaxLimitsTestMixin
@greggman greggman merged commit e99550b into gpuweb:main Jan 6, 2025
1 check passed
@greggman greggman deleted the test-maxSTB branch January 6, 2025 18:30
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