Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
On Sun, Apr 7, 2013 at 3:53 PM, Paul Berry <stereotype...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
