DFG LUT uses widely unsupported RGB16F

[cleak]

Describe the bug DFG lookup tables use RGB16F which is widely unsupported. This is generally fine for OpenGL, but Vulkan will refuse to create such textures. When running material_sandbox with Vulkan, this will trigger an assertion failure like:

FEngine (64 bits) created at 00000145CFDC6080 (threading is enabled)
FEngine resolved backend: Vulkan
Selected physical device 'GeForce GTX 1060' from 2 physical devices. (vendor 0x0x10de, device 0x0x1c20, api 0x0x40105f, driver 0x0x68c44000)
class utils::PostconditionPanic
in filament::Texture *filament::Texture::Builder::build(filament::Engine &):93
in file ..\..\filament\src\Texture.cpp
reason: Texture format 262184 not supported on this platform

To Reproduce Run material sandbox like:

samples\material_sandbox.exe --api=vulkan ..\..\assets\models\monkey\monkey.obj

Expected behavior material_sandbox should run.

Desktop (please complete the following information):

• OS: Windows 10
• GPU: GTX 1070
• Backend: Vulkan

Additional context It looks like this is a recent problem resulting from #853. Previously DFG used RG16F which has good support.

[romainguy]

Thanks for the report. I must say I am flabbergasted as to why RG16F would be commonly supported but not RGB16F (edit: alignment I suppose, 32 bit vs 48 bit).

[romainguy]

@bejado @prideout It sounds like the TextureReshaper used for Metal would be a good solution here? We'd just have to use RGBA16F I think. If that format isn't widely supported either we'll have to use two DFG LUTs

[romainguy]

Actually is this format truly not supported or is that our driver being paranoid @prideout?

[prideout]

According to gpuinfo.org, only 16% of all implementations support this, so yeah I need to use our reshaping stuff and update the getVkFormat function.

[romainguy]

It's extremely convenient to use an RGB16F texture for the DFG LUT — especially as I keep working on a new sheen parameter for the standard material model — but it opens a few questions:

• What is the impact on performance of the 3rd channel? It'll probably reduce the texture cache hit rate but I don't know whether it truly matters considering how the texture is indexed
• Should we use two RG16F samplers? The second one would currently have only one channel, it would break materials compatibility and burn yet another sampler which are at a premium on mobile
• If we go with RGBA16F anyway through the reshaper we could consider adding a fourth channel to the LUT for yet another BRDF (Disney diffuse for instance)

[pixelflinger]

@romainguy crazy idea, instead of using two RG16F samplers (b/c samplers are a limited resource), why not use a 3D texture? e.g. three R16F layers? or even two RG16F ones -- this way we don't pay the price when the 3d channel is not used (compared to RGBA16F). Now, granted, filament doesn't support 3D textures yet, but we really should and it wouldn't be too hard to add.

Another option would be to use a mip level -- it would have a lower resolution, but does it really matter?