Khronos Ratifies KTX 2.0

[phoronix]

Phoronix: Khronos Ratifies KTX 2.0

Just one week after having published the provisional Vulkan Video extensions, The Khronos Group has another exciting announcement today in the form of ratifying KTX 2.0...

https://www.phoronix.com/scan.php?page=news_item&px=Khronox-KTX2-Format

[CochainComplex]

Could this be used for dxvk/vkd3d in a "similar" manner as shadercache: Textures are going to be converted in this new format upfront and than be stored in a cache to avoid runtime texture loading overhead of the classic format?

[ms178]

Congrats to Richard Geldreich on getting Basis Universial adopted into this Khronos standard. I hope we consumers will get to see the fruits of this sooner rather than later.

[dragorth]

Could this be used for dxvk/vkd3d in a "similar" manner as shadercache: Textures are going to be converted in this new format upfront and than be stored in a cache to avoid runtime texture loading overhead of the classic format?

This would need to be special cased for each game engine or version of said game engine depending on the changes, so probably not. That means it could be done for say Unreal or Unity and cover a large number of existing titles, so maybe.

Each engine handles this differently, so it is important to realize this.

[CochainComplex]

This would need to be special cased for each game engine or version of said game engine depending on the changes, so probably not. That means it could be done for say Unreal or Unity and cover a large number of existing titles, so maybe.

Each engine handles this differently, so it is important to realize this.

Thx for pointing that out. Unfortunately I dont know enough about game engines and gfx apis to conclude it myself. My hope was that there is some universal directx texture loading function which could be bypassed/remapped.

[dragorth]

Thx for pointing that out. Unfortunately I dont know enough about game engines and gfx apis to conclude it myself. My hope was that there is some universal directx texture loading function which could be bypassed/remapped.

To be more technically, DX has its own formats, and an engine using those would not need to use KTX, as those formats are supported on most recent GPUs. (As in the last 10 yrs.) They aren't as size efficient as the latest and greatest, but they are faster than converting, which is what is being targeted here.

There are several ways to tackle memory pressure on the CPU to GPU link, and the first is raw throughput. PNGs have to be converted on the CPU, then sent to the GPU in an uncompressed format, because the compression takes too long in the CPU. (This is not so true in a small indie 2D game, but is true in any sizable 3D game.) So this handles that case by doing the conversion upfront, and while they are at it, using the best compression tech freely available at this time to reduce the requirements, which increases throughput, or technically the number of textures that can be loaded per second.

Where do I hope to see this used? The Dolphin emulator has support to external textures. If they adopted support for this, it would allow for better performance at 4k.

Also, keep in mind, shaders are designed to use the exact textures the engine specifies. Not ot get too technical, but the DX formats actually throw away info in the format to get smaller sizes, and the shaders are made while looking at that reduced quality. These formats make different tradeoffs. It can cause artifacting and other issues. Have you ever saved a JPEG, edited it and saved it as a JPEG again? Or converted a movie from one encoding to another and notice there is a difference? You are basically taking all the worst qualities of the first format and adding the worst qualities of the second format for a new image. Now you have lost quality, that you can't magically get back. (There is some interesting work with AI, check out the FF9 up-scaling project Moguri. ) This can manifest in onscreen glitches, blurry textures, off color textures, particle effects that don't look correct, and who knows what else.

Not all games will benefit from this, because engines do things like group all the textures together into one big texture, and now you may get worse compression than you originally thought. (MegaTextures, think id's Rage game, were a big thing in the industries for a bit, and is now in Unreal Engine by default, IIRC. You have to select the feature to use it, though.) These tend to be highly optimized already, so it would be difficult to see any major speed gains from this.

[Quackdoc]

IF I am understanding right, (I have not read khornos article yet) this will allow compressed images to be stored on vram AND decoded within the gpu? this is a massive preformance gain for any texture bound game. not only will the save vram usage which is a massive sink now, but also increase performance on games that need to rapidly load and unload textures. this would effectively kill the need for texture streaming (mip map streaming) to a large degree. This is very exciting indeed. especially considering that any vulkan game could benefit, and it is not engine specific.

[Azrael5]

Impressive. How long to get this new progress available?

[Jumbotron]

I'd love to see KTX used in conjunction with a Tile Based Deferred Rendering GPU like Imagination's PowerVR or it's inspired cousin as designed and optimized by Apple in their M1. The combination of an extremely efficient and VERY high quality texture compression paradigm in combination with a GPU that only renders parts of a scene that needs to be displayed and no more until such time as the next change in scene is needed could open the door to PS 5 quality graphics in the mobile space of phones, tablets and handhelds like a Nintendo Switch or equivalent. Not to mention head mounted VR or hyper realistic AR.

[polarathene]

Impressive. How long to get this new progress available?

Each software package needs to adopt support for such IIRC. So Blender, Three.JS (web js lib), Unity and Unreal, and so forth. Expect them to arrive at different times, and iirc with earlier glTF/KTX stuff support also varied.

Blender for example I'm pretty sure has stuck to one type of PBR workflow and chosen to neglect the other kind, import/export also didn't always have equivalent mapping of features, so you didn't always get what you'd expect, especially with import/export (load/save) of glTF files were not always retaining data even if Blender was the only tool involved I think..