[Mesa-dev] [v3 1/4] glsl: add ir_cache class for IR serialization (WIP)

[Tapani Pälli]

On 10/08/2013 11:03 PM, Eric Anholt wrote:
> Tapani Pälli <tapani.palli at intel.com> writes:
>
>> Patch introduces ir_cache class that can serialize a gl_shader
>> to memory with help of memory_writer class and also unserialize
>> it back with help of memory_map class.
>>
>> This can be used by the shader compiler to cache individual shaders
>> and skip lexing, parsing, type checking, AST->IR generation and
>> optimization rounds that happen during compilation.
>>
>> v2: fix builtin function handling in read_ir_function(), now
>> generated IR is identical with original
>>
>> v3: piglit crash fixes, dump more data
>>
>> Known issues / bugs / missing implementation:
>>
>> - constant structures not supported
>> - interfaces not supported
>> - no support for geometry shader emit_vertex, emit_primitive
>> - write/read file i/o likely not portable to some architectures
> We don't use templates in our C++ code -- it was one of the agreements
> for letting C++ into the project.
>
> I think the use of templates for the write() function looks convenient
> but is a bad idea in general.  You want to be clear about the types

ok, I guess same applies to reading (memory_map::read_value) as well, I 
will get rid of the templates.

Do you think following way would be ok?

--------- 8< ---------------
#define _W(type) inline int write(type *val) {\
    return write(val, sizeof(*val), 1, -1);\
}

_W(int)
_W(bool)
_W(unsigned)
_W(long)
_W(uint8_t)
_W(gl_texture_index)
_W(ir_node_type)
_W(ir_loop_jump::jump_mode)
_W(ir_expression_operation)
_W(GLbitfield64)
...
--------- 8< ---------------


> being written to files.  For example you've got some "long"s being
> written which means that they'll read back incorrectly when mixing
> 32-bit and 64-bit programs on the same system.  I'd rather see a set of

True, I think I can actually start to use a different type here, 
uint32_t should work ok for these cases, will check.

> explicit sized overloads so that the developer have a harder time making
> this mistake or similar ones like write(ir_variable *var).
>
> We'll also need to make sure that the driver in use gets put in the
> cache key along with the mesa sha, and probably the driconf
> configuration as well.

Thanks for your feedback, I will add dri driver information to the blob 
header.

Right now I'm working on the changes to have blobs with multiple shaders 
+ additional structures to get a whole program cached.

// Tapani