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

SoftGPU: Implement mipmapping #9673

Merged
merged 8 commits into from
May 9, 2017
Merged

Conversation

unknownbrackets
Copy link
Collaborator

@unknownbrackets unknownbrackets commented May 8, 2017

There's a few things left to fix, but this largely implements all the mipmapping outlined in #9621. The animations in #6357 work roughly as expected.

Things that remain:

  • Verify behavior of invalid mip mode 3.
  • Correctly handle pixel centers (using du and dv, I assume), especially for BR -> TL texturing.
  • Linear filtering / mipmaps for lines?
  • Check if linear filtering does anything at all for points (maybe for uneven UVs?)
  • Further refactoring for SIMD.

Crisis Core looks quite a bit better with this rounding. But, this does impact performance negatively overall.

-[Unknown]

This fixes several obvious issues in Crisis Core, but it's still wrong
when texcoords go the other direction.  Need to use the deltas.
These should only be used for CLUT4.
It seems like this is what the PSP does, or maybe this is just correcting
for floating point error...
float detail;
switch (gstate.getTexLevelMode()) {
case GE_TEXLEVEL_MODE_AUTO:
detail = std::log2f(std::abs(std::max(ds, dt)));
Copy link
Owner

@hrydgard hrydgard May 8, 2017

Choose a reason for hiding this comment

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

optimization idea: instead of using the accurate log2f, pick apart the max(ds, dt) floating point number and use the exponent (biased appropriately) for the detail level and the mantissa as the interpolation factor towards the next one. I believe that's what most hardware implementations actually do.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sounds like a good plan. Wasn't worrying about optimization overly yet. Probably forgot <cmath> for log2f anyway...

-[Unknown]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, as expected this gave a pretty decent improvement to performance - 68 -> 73 FPS in the #6357 animation.

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented May 8, 2017

Travis looks a bit unhappy, coincidentally it's about the log2f operation.

This is probably what the hardware does and much faster.
These now affect softgpu, so let's not disable them.
@hrydgard hrydgard merged commit 6d6c1f6 into hrydgard:master May 9, 2017
@unknownbrackets unknownbrackets deleted the softgpu branch May 11, 2017 03:59
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