[Mesa-dev] [PATCH 00/13] i965 vs: Split vec4_visitor into two classes.

[Paul Berry]

On 16 November 2011 11:07, Paul Berry <stereotype441 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111116/73a947ec/attachment.htm>