[Mesa-dev] Support for EXT/ARB_geometry_shader4

Brian Paul brianp at vmware.com
Fri Jul 27 10:55:45 PDT 2012

On 07/27/2012 09:40 AM, Bryan Cain wrote:
> Some of you already know about this from IRC, but recently I've been
> working on adding support for GL_EXT_geometry_shader4 and
> GL_ARB_geometry_shader4 (which are essentially identical) to Mesa.  A
> significant amount of the required code was already there from Zack
> Rusin's work on geometry shaders about 2 years ago (before the new GLSL
> compiler was merged), so the bulk of my changes are adding support to
> the GLSL compiler and glsl_to_tgsi, which is still not a small task.
> Anyway, as of yesterday, all of the GLSL demos in mesa/demos that use
> EXT/ARB_geometry_shader4 are working fully in my branch with softpipe.
> There are still some things that need doing and/or fixing before it
> should be considered for merging into master, but for now, my geometry
> shader work (including future updates) can be found in a branch of my
> Mesa repository on GitHub at:
> https://github.com/Plombo/mesa/tree/geometry-shaders .
> It's worth noting that geometry shaders in GL 3.2 (GLSL 1.50) core are
> slightly different than the geometry shaders in the EXT and ARB
> extensions.  However, the main change in the core version is a change in
> the way inputs are accessed which is rather TGSI-unfriendly, so when
> GLSL 1.50 is implemented, we will have to lower GS inputs to the
> extension way of doing things.  So all of this code is in fact necessary
> for GL 3.2 core even though it only implements the extensions.

Nice work!  It's great to see GS work getting done.

I imagine you'll split up your patch into pieces for review.

I did a quick review of your patch and only noticed little nits.

static int
vertices_per_prim(int prim)

"GLenum prim"

if (array == NULL) continue;

Should put the continue on the next line.

The indentation for the hunk at line 2383/2488 in linker.cpp looks off.

Mesa has a MESA_GEOMETRY_PROGRAM #define that's the same as 
GL_GEOMETRY_PROGRAM_NV.  We should probably get rid of the former at 
some point.


More information about the mesa-dev mailing list