fix(daemon): support Texture3D depth slices#269
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughTexture descriptor and resource responses now expose depth, dimension, and texture type metadata. CLI tables include a ChangesTexture metadata and slice validation
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
Support depth-slice statistics and expose depth metadata for true 3D textures.
Why
Related to #268. RenderDoc reports
arraysize == 1forTexture3D, so validatingtex-stats --sliceagainst the array size rejects valid depth slices.This PR intentionally leaves #268 open for reporter-side verification with the private
Android GLES capture.
How
Texture3Dslices againstmax(1, depth >> mip)while retaining array-sizevalidation for array textures and cubemaps.
depth,dimension, andtexture_typeto resource and descriptor metadata.Test plan
pixi run check(3104 passed, 6 skipped, 93.25% coverage)26 passed)Summary by CodeRabbit
New Features
Bug Fixes