Kfx format resurrection

Reprinted please indicate the source for the klayge game engine, this article address for http://www.klayge.org/2012/02/20/kfx%e6%a0%bc%e5%bc%8f%e7%9a%84%e5%a4%8d%e6%b4%bb/

 

Old users remember that before klayge 3.9,. fxml used to represent effect must be compiled offline using a python compiler to generate a. kfx format for runtime. Rapidxml is introduced in 3.9, which can be used to read XML files directly at runtime. The process becomes shorter and the development efficiency is improved. However, over the past two years, the more complex the shader writes, the more time it takes to compile the shader. It is a waste of time and computing to compile the shader every time it is loaded.

Klayge model format. meshml also had this problem. Later, a JIT was used to dynamically load the XML. meshml is compiled into binary. model_bin greatly improves the loading speed. Neither offline compilation nor read efficiency is required. Therefore, introducing an effect JIT is also a matter of course. Therefore, after many years, the kfx format was revived with full blood.

The original kfx goal was to save effect into binary for runtime reading. The goal is to reduce the waste of time and computing. Therefore, although the extension is still kfx and the file to be installed is still a binary effect, the file format and capabilities do not need to be compatible with the previous one. The new format not only contains the original binary effect, but also stores the shader compiled by different APIs in the same file. Currently, HLSL bytecode, glsl, and essl are supported. Different rendering plug-ins can read data in the format they can handle. In the future, more binary formats will be supported, especially on OpenGL ES, to cope with the weak OpenGL ES glsl compiler.

By the way, the. fxml_bin format on 4.0 is described. Because there is no CG on Android, we introduced. fxml_bin in the emergency, and put the JIT essl in the PC. In this way, only essl can be read directly on Android, and CG is not involved. However, because it is only an emergency solution that has not been carefully designed, each fxml_bin can only save one shader. So that a fxml may compile and generate many different fxml_bin files in the directory. Now you can delete all of them.

Now let's compare the loading speed with the new kfx. The shader, deferred rendering, is the most complex example.

	Before using kfx (seconds)	After kfx is used (seconds)	Acceleration (seconds)
D3d11	4.8	2.6	2.2
OpenGL	6.0	2.6	3.4
OpenGL ES	28.2	25.3	2.9

The d3d11 plug-in saves about 2.2 seconds to assemble and compile HLSL. The shader of OpenGL needs to go through the CG-> traditional glsl-> modern glsl process. After kfx is used, all of these are saved, saving the most time. OpenGL ES and OpenGL process are the same, but essl is relatively simple, so the acceleration is not so obvious. It should be noted that OpenGL ES still needs 25 seconds to basically load the texture. The OpenGL ES simulator does not support dxt5, sRGB, and so on. It needs to be dynamically converted to abgr8 during loading, which is quite slow. In the future, a platform compiler may be developed to compile resources offline for different platforms in the most suitable format. This problem is fundamentally solved.