SMOL-V Is A Compression Effort On Vulkan's SPIR-V

[Kemosabe]

Despite the fact that the majority of Linux games are still of the quality of hobby projects, ongoing efforts regarding Linux gaming performance let me hope that the current strategy of VALVE/Developers/GPU vendors is letting Linux mature before AAA ports are being attempted in a larger scale.

Nope. I'm just acknowledging what you said, a post flagging my post as "zero content troll post" would be a "zero content troll post".
You didn't claim nor I did acknowledge anything about my post being a "zero content troll post".
Your English writing skills are improving, but not yet at my level.

Would you kindly stop wasting everybody's time with your spam?

[starshipeleven]

Would you kindly stop wasting everybody's time with your spam?

Don't feed the troll.

[Ancurio]

I'm slightly questioning the rationale behind compressing your 2mb of shaders by a few percent more when you've got 200mb of art assets anyway

[starshipeleven]

I'm slightly questioning the rationale behind compressing your 2mb of shaders by a few percent more when you've got 200mb of art assets anyway

shaders are executable code running on GPU, art assets are not. So their size influences performance more than art assets. Although meshes and textures and other stuff is compressed too.
I'm suspecting that it works like in most other areas, the time the processor (CPU or GPU, in this case it's GPU) needs to decompress the code is still faster than the time needed to read a longer file.

[kalrish]

shaders are executable code running on GPU, art assets are not. So their size influences performance more than art assets. Although meshes and textures and other stuff is compressed too.
I'm suspecting that it works like in most other areas, the time the processor (CPU or GPU, in this case it's GPU) needs to decompress the code is still faster than the time needed to read a longer file.

SPIR-V is not run as-is on the GPU, but translated by the driver to GPU code. If I've understood it correctly, SMOL-V is an alternative serialization format (alternative to SPIR-V, I mean. SPIR-V is just that, a serialization format). Of course, it's not part of Vulkan (the Vulkan spec), so applications wishing to use it will have to decompress it themselves and extract the SPIR-V bytecode, which is what Vulkan drivers understand.

I'm slightly questioning the rationale behind compressing your 2mb of shaders by a few percent more when you've got 200mb of art assets anyway

I'm with Ancurio, though. Given the size of game data, shrinking shaders by a few MBs shouldn't matter much (unless I'm missing something and these SPIR-V shaders are really huge), and shader loading could even be made slower (I doubt that, though; optimization is likely the slowest stage in the shader loading process).

[dragorth]

This is mainly about first run game and level load times. The first run pulls the shader from the disk, which is the slowest part of the chain, especially on low end phone devices. The CPU can transform the shader much faster than pulling the uncompressed shader from the disk. This is why Microsoft's Windows 10 compresses its OS files on SSDs, cause they still get a performance boost.

After the GPU runs the shader the first time, the driver/game can save the cache to improve performance after the fact, but first runs are important for first impressions. Most games are never played past a few minutes, so getting as much time for the player in the game to showcase its merits is important to them.

[Ancurio]

This is mainly about first run game and level load times. The first run pulls the shader from the disk, which is the slowest part of the chain, especially on low end phone devices. The CPU can transform the shader much faster than pulling the uncompressed shader from the disk. This is why Microsoft's Windows 10 compresses its OS files on SSDs, cause they still get a performance boost.

After the GPU runs the shader the first time, the driver/game can save the cache to improve performance after the fact, but first runs are important for first impressions. Most games are never played past a few minutes, so getting as much time for the player in the game to showcase its merits is important to them.

I wonder if it would make sense on Android to have the creation and back-to-disk serialization of the pipeline cache be part of the install process. This would essentially null out any possible "first run" hiccups. Also, the GPU is not involved in this process.

Of course, reading a giant cache blob on every start might also be slower than just progressively recompiling each time a given shader is required (possibly in a background thread before it's actually needed). Probably depends on how many shader combinations (ie. individual pipelines) your game uses.

[coder111]

And kudos go to Michael for getting his website to display Lithuanian characters right, and getting the name right

Labas

Cool, another Lithuanian, and working in Unity3D.

[starshipeleven]

SPIR-V is not run as-is on the GPU, but translated by the driver to GPU code. If I've understood it correctly, SMOL-V is an alternative serialization format (alternative to SPIR-V, I mean. SPIR-V is just that, a serialization format). Of course, it's not part of Vulkan (the Vulkan spec), so applications wishing to use it will have to decompress it themselves and extract the SPIR-V bytecode, which is what Vulkan drivers understand.

Still does not invalidate the big part of my point. CPU usually decompresses far faster than the storage system can read, so compression almost always leads to faster read times in these situations.

[GreatEmerald]

And kudos go to Michael for getting his website to display Lithuanian characters right, and getting the name right

Indeed.

This reminds me of Ian Stakenvicius (axs), a prominent Gentoo and Mozilla dev. He's Canadian, but sounds like from an expat family (though how the "n" got moved to the end I have no clue).

Labas

Sveikas.