On 16 November 2011 11:07, Paul Berry <stereotype...@gmail.com> wrote:
> 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. > I should also mention: if you'd like to look at these patches in context, you can pull them from my github repo (git:// github.com/stereotype441/mesa.git). 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: https://github.com/stereotype441/mesa/blob/vec4-split/src/mesa/drivers/dri/i965/brw_vec4.h
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
