In order to implement transform feedback on Gen6, we need to create a geometry shader program that will stream out the transformed vertices. It makes sense to re-use parts of the vec4_visitor infrastructure to do this, because (a) VS and GS handle data very similarly, (b) it allows us to take advantage of the optimization and register allocation code in vec4_visitor, and (c) in the long run when we add support for GLSL geometry shaders, we are going to need to use the vec4_visitor infrastructure to compile them.
This patch series gets us ready for re-using parts of vec4_visitor, by breaking it into a base class containing the parts we are likely to re-use, and a derived class containing the parts we aren't. The base class, vec4_generator, is responsible for code generation, register allocation, and optimization; it is independent of GLSL IR (with one trivial exception), and mostly independent of the type of shader being compiled. The derived class, vec4_visitor, is responsible for visiting the GLSL IR and performing vertex-shader-specific actions. This split was already implicitly present in the code; this patch series merely makes it more explicit. The idea is that for now, we can make a class that derives from vec4_generator to do transform feedback, and we won't have to worry too much about interactions with the GLSL IR visiting code in vec4_visitor. Later, when we add support for GLSL geometry shaders, we'll have to do further work on vec4_visitor, but we won't have to touch vec4_generator very much. Patches 01-11 are all preparatory refactoring: they make small adjustments to the functioning of vec4_visitor so that the separation between its IR visiting parts and its code generation parts is a little more strict. Patch 12 splits the classes up, and then patch 13 reformats the class declarations to clarify the relationship between the two classes. The split isn't perfect yet; there are a few places where vec4_generator still makes implicit assumptions that are vertex-shader specific (particularly in register allocation), and there are a few places where vec4_visitor still does things that arguably should be part of code generation (such as setting up scratch registers). But I think this is close enough that we can clean those up with later patches on an as-needed basis. Note: To ease reading the diffs, I didn't make any effort to move code between .cpp files. As a result, vec4_visitor and vec4_generator code are intermingled in brw_vec4_visitor.cpp, brw_vec4_emit.cpp, brw_vec4.cpp, brw_vec4_copy_propagation.cpp, and brw_vec4_reg_allocate.cpp. Once this patch is reviewed and we've settled on how we want the classes to be split up, I'll make a follow-up patch that rearranges the .cpp files to match the changes to the class structure. [PATCH 01/13] i965 vs: Remove dead code from the vec4_visitor class. [PATCH 02/13] i965 vs: Make reg_allocate() return total_grf. [PATCH 03/13] i965 vs: Return last_scratch from move_grf_array_access_to_scratch() [PATCH 04/13] i965 vs: Make first_non_payload_grf an explicit function arguments. [PATCH 05/13] i965 vs: Move brw_set_access_mode() call into generate_code(). [PATCH 06/13] i965 vs: Move the call to reg_allocate() inside of generate_code(). [PATCH 07/13] i965 vs: Streamline the way fail is tracked. [PATCH 08/13] i965 vs: Add get_debug_flag() [PATCH 09/13] i965 vs: Add get_debug_name(). [PATCH 10/13] i965 vs: Make a separate optimize() method. [PATCH 11/13] i965 vs: Make get_assignment_lhs() a method [PATCH 12/13] i965 vs: Separate IR visiting from code generation in vec4_visitor; [PATCH 13/13] i965 vs: Rearrange class declarations. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
