An actual 3D block based format would be useful, currently on PC at least the only formats are for 2D textures. They do work for 3D textures, but in 2D slices so the result is not as good as it could be. Also the only 1 channel format is BC4 which is .5 byte per entry, and has 2 encodings modes, but the 2nd one is mostly useless for an SDF, so that is a waste.
I'd prefer a 1 per byte entry option for higher detail, no need for any fancy modes, needs to be simply and fast to encode so it can be done realtime.
IDK about this post though, separating the block min/max into a separate memory location from the indices doesn't make much sense, you could just access a less detailed mip if that is what you want.
Apples M-series chips have ASTC if you count those as desktop, but yeah neither AMD or Nvidias discrete GPUs have it. Desktop and console chips usually only have BC, mobile chips usually only have ASTC, and the few chips which straddle the line between those worlds have both (e.g. Nvidia Tegra and Apple M).
> This makes SDF amenable to implementation in GPU hardware, though to date no hardware has been designed specifically to accelerate SDF.
This isn't entirely correct. Nvidia GPUs can perform interpolation on 3D textures, which is specifically useful for performing finer distance queries on a 3D SDF.
Aren’t the TMUs on AMD GPUs still cap at FP16 at least for advertised throughput?
NVIDIA TMUs historically offered higher precision and about double the throughput as well as supported other edge cases such as sub pixel sampling much more effectively than AMD GPUs and at least recalling some failure states in low level APIs AMD seems to at least do certain things in shaders which were loaded by the driver when certain API functions were called rather than having native instructions for that.
Or maybe we're talking past each other - bandwidth and interpolation requirements mean that lower precision does tend to be faster - even on nvidia. unorm8 is often the quoted "texels/second" precision, as to this day rgb888 is the "most common" texture format in games/apps/desktop environments. I think GCN had fp16/int16 at 1/2 that (I think RDNA increased that to 1/1), fp32/int32 at 1/4 and fp64 at 1/8. But that's pretty much the same as nvidia's texture filtering rates, abut I don't think there's a "hard cap" or internal limit of fp16 precision?
An actual 3D block based format would be useful, currently on PC at least the only formats are for 2D textures. They do work for 3D textures, but in 2D slices so the result is not as good as it could be. Also the only 1 channel format is BC4 which is .5 byte per entry, and has 2 encodings modes, but the 2nd one is mostly useless for an SDF, so that is a waste.
I'd prefer a 1 per byte entry option for higher detail, no need for any fancy modes, needs to be simply and fast to encode so it can be done realtime.
IDK about this post though, separating the block min/max into a separate memory location from the indices doesn't make much sense, you could just access a less detailed mip if that is what you want.
ASTC has support for 3D blocks. But, I don't know how widespread support is for desktop GPUs...
https://en.wikipedia.org/wiki/Adaptive_scalable_texture_comp...
For example, apparently support in OpenGL is simply not available.
https://www.khronos.org/opengl/wiki/ASTC_Texture_Compression...
Ya it does, but desktop GPUs don't support ASTC(or if they do it isn't exposed)
Apples M-series chips have ASTC if you count those as desktop, but yeah neither AMD or Nvidias discrete GPUs have it. Desktop and console chips usually only have BC, mobile chips usually only have ASTC, and the few chips which straddle the line between those worlds have both (e.g. Nvidia Tegra and Apple M).
What about OpenVDB? .. certainly seems to be used for voxel data in VFX quite a lot (I work at a VFX company) There's NanoVDB too that works on GPUs.
OpenVDB is high level description for voxel data, not a compressed format that GPU hardware supports.
Metal offers 3D textures, and they are nice for SDFs.
> This makes SDF amenable to implementation in GPU hardware, though to date no hardware has been designed specifically to accelerate SDF.
This isn't entirely correct. Nvidia GPUs can perform interpolation on 3D textures, which is specifically useful for performing finer distance queries on a 3D SDF.
Not sure why you feel the need to call out Nvidia. Interpolation of 3D textures has been a standard feature in graphics APIs for a very long time.
But the author is correct in that this isn't specifically geared towards SDFs.
Aren’t the TMUs on AMD GPUs still cap at FP16 at least for advertised throughput?
NVIDIA TMUs historically offered higher precision and about double the throughput as well as supported other edge cases such as sub pixel sampling much more effectively than AMD GPUs and at least recalling some failure states in low level APIs AMD seems to at least do certain things in shaders which were loaded by the driver when certain API functions were called rather than having native instructions for that.
I don't think so? It's not something I've ever noticed, though have only been working on AMD GPUs since GCN (~12 years ago)
I'm not sure the ISA even allows some "low precision internal calculations" mode on image samplers
GCN definitely only effectively supported FP16 on the TMUs not sure about RDNA.
I'm not sure that meshes with my understanding.
Do you have any links you can share?
Or maybe we're talking past each other - bandwidth and interpolation requirements mean that lower precision does tend to be faster - even on nvidia. unorm8 is often the quoted "texels/second" precision, as to this day rgb888 is the "most common" texture format in games/apps/desktop environments. I think GCN had fp16/int16 at 1/2 that (I think RDNA increased that to 1/1), fp32/int32 at 1/4 and fp64 at 1/8. But that's pretty much the same as nvidia's texture filtering rates, abut I don't think there's a "hard cap" or internal limit of fp16 precision?