[Mesa-dev] [PATCH 00/17] i965/vs: Generalize VS compiler back-end in preparation for GS.

[Jordan Justen]

Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

On Sun, Apr 7, 2013 at 3:53 PM, Paul Berry <stereotype441 at gmail.com> wrote:
> This patch series lays the groundwork for the i965 geometry shader
> back-end by separating the functions and data structures which are
> specific to vertex shaders from those that can also be used to compile
> geometry shaders.  (Following a naming convention that is already
> present in the codebase, this common code is referred to as "vec4"
> code, since in the future we should be able to use it for any shader
> stage where the hardware expects a pair of vec4s to be stored in each
> register.  This includes tessellation control and tessellation
> evaluation shaders.)
>
> In particular, the following structs/classes have been split into a
> base class containing vec4-generic data, and a derived class
> containing VS-specific data:
>
> - brw_vs_compile (new base struct is brw_vec4_compile)
> - brw_vs_prog_key (new base struct is brw_vec4_prog_key)
> - brw_vs_prog_data (new base struct is brw_vec4_prog_data)
> - vec4_visitor (new derived class is vec4_vs_visitor)
>
> In the case of vec4_visitor, standard C++ inheritance is used, and
> VS-specific behaviours are moved into virtual functions.  The other
> three cases use C-style inheritance (the derived struct has an
> explicit "base" element, and there are no virtual functions), since
> these structs need to be accessible from plain C code.
>
> In addition, small modifications have been made to the vec4_generator
> class and the brw_compute_vue_map() function to generalize them for
> use by both vertex and geometry shaders.
>
> To keep merge conflicts to a minimum (since this patch series has been
> in development for several weeks), I've tried to minimize the amount
> of code motion introduced by this change.  As a result, the patch
> series leaves vec4_vs_visitor functions scattered in several files
> (brw_vec4.cpp, brw_vec4_visitor.cpp, and brw_vec4_vp.cpp).  Once this
> series lands, I'd like to follow up with a patch series that moves all
> of the vec4_vs_visitor functions to a new brw_vec4_vs_visitor.cpp
> file, and moves the class declaration to a corresponding header.  I'll
> wait until this patch series has landed before starting on that, and
> try not to do it while anyone is in the middle of major VS back-end
> work.
>
> Note that this patch series must be applied atop the patch "i965/vs:
> Fix DEBUG_SHADER_TIME when VS terminates with 2 URB writes", which I
> sent out for review this morning.  You can find the complete series in
> context at branch "gs-backend-prep" of
> git://github.com/stereotype441/mesa.git.
>
> In order to verify that it's actually possible to build geometry
> shader functionality atop these changes, I have begun prototyping an
> implementation of geometry shaders which passes all existing geometry
> shader Piglit tests.  (Sadly, there are many more tests left to write,
> and features left to implement!)  I'll be sending out those patches in
> the coming month(s), as they mature.  You can find that series in
> branch "gs" of git://github.com/stereotype441/mesa.git.  Note that the
> "gs" branch is *highly volatile*, so if you want to base work on it,
> please let me know so we can coordinate.
>
> Piglit-tested on i965/Gen7--no regressions.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev