On 10/08/2013 11:03 PM, Eric Anholt wrote:
Tapani Pälli <[email protected]> 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
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
