The Mesa On-Disk Shader Cache Has Been Revised Again (V5)

[Ancurio]

That's why AMD team wants to work on splitting their "shaders" into parts that are constant and parts that depend on the opengl state. Something Vulkan made explicit. Then shader cache would only contain that constant core, and would be reusable regardless of additional settings game/app provide.

Also, not having to constantly recompile stuff when GL state is fiddled with helps! Btw. why "wants to work on"? Hasn't Marek completed that task?

[raster]

Sure, but such an implementation would unfortunately be useless with Mesa, which doesn't implement glProgramBinary in any of its drivers. From a cursory look at the patches, the majority seems to deal with proper (de/)serialization, not bookkeeping.

The point is not if its useful with mesa or not. The point is that it has nothing to do with language and a shader cache is really trivial to implement in C assuming you just have enough utility provided in libraries. same for any language. if such utility is not there it has to be written.

get_program_binary extn is rather widely implemented outside of mesa and doesn't need mesa to implement its own cache as software higher up the stack already can and does do this for performance reasons. nvidia do and various egl/gles embedded drivers implement it. it's rather common.

[Ancurio]

get_program_binary extn is rather widely implemented outside of mesa and doesn't need mesa to implement its own cache as software higher up the stack already can and does do this for performance reasons. nvidia do and various egl/gles embedded drivers implement it. it's rather common.

You should really reread my post. Most of Timothy's patches do work that is very similar to getProgramBinary. Of course you can implement a cache in a few hundred lines of C when 99% of the hard work is done for you by the dirver (ie. proper program serialization).

That's like saying "LUL writing a compiler in C is super easy, just call execv("cc", argv); it even works on most unices!".