On 16 November 2011 11:07, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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. </blockquote></div> I should also mention: if you'd like to look at these patches in context, you can pull them from my github repo (git://<a href="http://github.com/stereotype441/mesa.git">github.com/stereotype441/mesa.git</a>). The branch is called "vec4-split". If you'd like to see what the final vec4_generator and vec4_visitor classes look like, you can view them here: <a href="https://github.com/stereotype441/mesa/blob/vec4-split/src/mesa/drivers/dri/i965/brw_vec4.h">https://github.com/stereotype441/mesa/blob/vec4-split/src/mesa/drivers/dri/i965/brw_vec4.h</a>