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

[trackers] move common logic into TextureStateSet #6689

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

teoxoy
Copy link
Member

@teoxoy teoxoy commented Dec 9, 2024

No description provided.

@teoxoy teoxoy requested a review from cwfitzgerald December 9, 2024 16:07
@teoxoy teoxoy requested a review from a team as a code owner December 9, 2024 16:07
@jimblandy
Copy link
Member

@teoxoy Is this preparation for replacing TextureUses::COMPLEX with an Option in TextureStateSet::simple?

@teoxoy
Copy link
Member Author

teoxoy commented Dec 9, 2024

It was but since we decided last week not to focus on this I only put up this PR for the work that I already did.

}

/// SAFETY: `index` must be in bounds.
unsafe fn get(&self, index: usize) -> SingleOrManyStates<TextureUses, &ComplexTextureState> {
Copy link
Member

Choose a reason for hiding this comment

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

Should these all have names containing unchecked? They are all marked unsafe anyway, but in the Rust standard library, methods named get and get_mut are checked.

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe? My counterargument would be that TextureStateSet is not broad/generic as the standard library is (we only have unsafe methods here but not their safe counterparts).

I don't mind adding _unchecked though - let me know.

Copy link
Member

Choose a reason for hiding this comment

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

My feeling is that unchecked would be helpful to readers.


strict_assert!(index < self.set.simple.len());

strict_assert!(if self.metadata.contains(index)
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't this condition (self.metadata.contains(index)) get dropped if we replace all this with a call to TextureStateSet::tracker_assert_in_bounds? (Similarly in subsequent functions.)

Copy link
Member Author

Choose a reason for hiding this comment

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

It does but it's already checked above in self.metadata.tracker_assert_in_bounds(index);.

Copy link
Member

@jimblandy jimblandy Dec 10, 2024

Choose a reason for hiding this comment

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

ResourceMetadata::tracker_assert_in_bounds does not actually assert that index is a member of the ResourceMetadata, only that the entries at index in owned and resources are consistent.

Copy link
Member Author

Choose a reason for hiding this comment

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

ResourceMetadata::tracker_assert_in_bounds does not actually assert that index is a member of the ResourceMetadata

Doesn't the strict_assert!(index < self.owned.len()); do that? ResourceMetadata::contains tries to lookup in self.owned.

@cwfitzgerald cwfitzgerald self-assigned this Dec 11, 2024
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.

3 participants