NHacker Next
login
▲Mipmap selection in too much detailpema.dev
53 points by luu 3 days ago | 13 comments
Loading comments...
pema99 3 days ago [-]
Author here - I imagine this is a bit too niche to get much traction on HN. There's a bit of discussion on bsky https://bsky.app/profile/pema99.bsky.social/post/3lotdtgowf2...
boulos 5 hours ago [-]
Great writeup!

I can't tell from your GLSL if these would have forced FMAs for a lot of the intermediate product sums. That would probably be a non-trivial effect, particularly for your large anisotropy cases.

The Heckbert paper also describes the basic theory, but you would want to supplement with some of the offline rendering work that followed it. OpenImageIO (OIIO) is pretty widely used, and has gone through several iterations of bug fixing like https://github.com/AcademySoftwareFoundation/OpenImageIO/pul...

But for your purposes, you probably just need to find all the magic epsilons and sign checks to make it match.

DDoSQc 49 minutes ago [-]
This is great! Would've been really useful a couple months ago when I was refactoring Lavapipe's texture filtering. I worked off the Vulkan spec, which doesn't mention the elliptical transformation. I did notice that the spec says:

> The minimum and maximum scale factors (ρmin, ρmax) should be the minor and major axes of this ellipse.

Where "should" probably means some transformation can be applied (would be "must" otherwise).

Now I'm tempted to implement your visualizations so I can compare my work to your hardware references, and spend more hours getting it closer to actual hardware.

AshleysBrain 1 hours ago [-]
Perfect blog post for HN IMO - any blog title involving "in too much detail" will probably do well! Great job with the post, the visualizations are fantastic.
hmage 1 hours ago [-]
I have a hunch nvidia's mipmapping algorithm changes if you open nvidia control panel and change texture filtering to "high performance" vs "high quality"
PaulDavisThe1st 5 hours ago [-]
Totally fantastic article. I don't do work that overlaps with this at all, but even after 37+ years as a C++ programmer, I found this enlightening, engaging and informative. Thank you very much.
Agentlien 4 hours ago [-]
This was a wonderful article! I love this kind of exploration.
lloeki 2 hours ago [-]
I for one liked the article! Great visualisations.

There's a bit of nostalgia ;) Brought me back to the days where GL display lists were the fancy thing to do and any kind of non-ff shader were but a wild dream.

ImHereToVote 3 hours ago [-]
Nvidia has a quite blocky MIP selection. Did an Nvidia engineer decide that consumers don't notice, and fixed functioned the hell out of it?
ImHereToVote 3 hours ago [-]
This is very relevant to what I'm doing. I'm trying to reproduce the MIP pipeline to get anti-aliased procedural details in fragment. specifically converting high frequency details into roughness.
aeonik 2 days ago [-]

    "You couldn’t implement these functions yourself - they are magic intrinsics which are implemented in hardware"
But why?
pema99 2 days ago [-]
There simply isn't another way to access registers from one 'thread' on another thread without using an intrinsic. You need that to calculate finite differences. For a long time, the only option was ddx()/ddy(). Now we also wave intrinsics, which you couldn't implement yourself either.
lifelesson701 32 minutes ago [-]
Ap Kon he