[Mesa-dev] Geometry shader update, and a course correction

[Alex Deucher]

On Mon, Jul 22, 2013 at 1:42 PM, Paul Berry <stereotype441 at gmail.com> wrote:
> On 21 July 2013 23:14, Ian Romanick <idr at freedesktop.org> wrote:
>>
>> On 07/19/2013 11:48 AM, Paul Berry wrote:
>>>
>>> (TL;DR: geometry shaders are humming along, but because of a hitch I've
>>> run into, I'm going to change gears and implement GLSL 1.50-style
>>> geometry shaders first rather than ARB_geometry_shader4 functionality.
>>> This means some piglit tests will need to be rewritten).
>>>
>>> Hello all--
>>>
>>> As some of you may have noticed, I've spent the last several weeks
>>> writing a number of geometry shader tests and fixinging my "gs" branch
>>> (on https://github.com/stereotype441/mesa.git).  I'm happy to report
>>> that it's working better than ever: I now have the following features
>>> working in geometry shaders on Intel drivers:
>>>
>>> - Texturing.
>>> - Built-in uniform variables.
>>> - Interactions with ARB_shader_texture_lod,
>>> ARB_shading_language_packing, ARB_texture_cube_map_array,
>>> ARB_texture_multisample, ARB_texture_rectangle,
>>> ARB_uniform_buffer_object, and EXT_texture_array.
>>> - Mixing user-defined geometry shaders with fixed-function fragment
>>> shaders.
>>> - gl_PointSizeIn, gl_PrimitiveIDIn, gl_PrimitiveID, gl_ClipVertex,
>>> gl_ClipDistanceIn, and gl_ClipDistance (including several important
>>> corner cases of gl_ClipDistance that were previously broken, such as
>>> bulk assignment).
>>> - Color clamping.
>>>
>>> I've done all of this work using the ARB_geometry_shader4 version of
>>> geometry shaders; my intention was to get that working first, then
>>> introduce additional code to support GLSL 1.50-style geometry shaders.
>>> This was partly motivated by the fact that Bryan Cain's initial work on
>>> geometry shaders was done using ARB_geometry_shader4, and partly
>>> motivated by the fact that it's our standard development practice in
>>> Mesa to develop features as extensions first, and then only support a
>>> core feature once all of the extensions it includes have been finished.
>>> However, I've now run into hitch that's making me want to change course
>>> and implement GLSL-1.50 style geometry shaders first.  It's a bit of a
>>> long story so buckle up:
>>>
>>> In GLSL 1.50, the way you specify the input primitive type for a
>>> geometry shader is using a layout qualifier in the shader source code,
>>> so it is known at compile time.  Whereas in ARB_geometry_shader4, the
>>> way you specify the input primitive type is using
>>> glProgramParameteriARB() prior to linking.  This means that the input
>>> primitive type isn't known at compile time.
>>>
>>> That's a problem because ARB_geometry_shader4 provides for a read-only
>>> built-in constant called gl_VerticesIn, which is the number of vertices
>>> in each geometry shader input primitive (e.g. if the input primitive
>>> type is "triangles", gl_VerticesIn is 3).  Mesa does not currently
>>> support constants whose value is determined at link time, since constant
>>> folding, determination of explicit array sizes, and a lot of
>>> constant-related error checking happen at compile time.  To work around
>>> this, the "gs" branch currently treats gl_VerticesIn as a varying input
>>> during compilation, and then at link time replaces any references to it
>>> with the appropriate constant value.
>>
>>
>> Oh dear.  That's... awful.
>>
>> There is another possible work-around for this problem, but I don't know
>> that it's any better.  gl_VerticesIn has a limited set of possible value: 1,
>> 2, 3, 4, and 6.  We could ast-to-hir for each of those values.  We'd then
>> pick the "right" one link time.  There would also be some weirdness with
>> cases were only a subset compile (e.g., because the shader does something
>> like 'float foo[gl_VerticesIn-2];' which would fail to compile when
>> gl_VerticesIn <= 2).
>
>
> Huh, interesting idea.  I can't decide if it would be any better either.
> It's certainly worth keeping in mind.
>
>>
>>
>> Before committing to this route we should:
>>
>> 1. Survey known apps (e.g., on Steam) to see if there are any apps that
>> try to use OpenGL 3.0 + GL_ARB_geometry_shader4.
>
>
> I tried to look at this with Ken, but it wasn't obvious how to figure this
> out.  We tried running "strings" on all of Ken's steam games, and it matched
> files in a few games, but it wasn't clear whether that was because those
> games used libraries that are aware of geometry shaders (e.g. GLEW), or
> because they would really make use of geometry shader functionality if it
> were available.  Also, if a game is capable of using either
> ARB_geometry_shader4 or GLSL 1.50 (depending on which is supported), then
> that wouldn't really be an argument for supporting ARB_geometry_shader4,
> because the game would work fine once OpenGL 3.2 is supported.
>
>>
>>
>> 2. Determine whether there is any hardware supported by Mesa that will
>> never get OpenGL 3.0 (due to, say, one missing feature), but might get GLSL
>> 1.30 + GL_ARB_geometry_shader4.
>
>
> On the Intel side, I suppose we could theoretically support geometry shaders
> on Gen4-5, which will never get to GL 3.0 due to lack of MSAA.  But
> realistically, I'm doubtful that any program that requires geometry shaders
> would be remotely usable on Gen4-5.  A further problem with supporting
> geometry shaders on Gen4-5 is that we currently use the geometry shader
> stage of Gen4-5 to decompose quads and line loops (which are not natively
> supported by the hardware).  So we would have to At the moment I'm not even
> planning to work on Gen6 geometry shaders until Gen7 geometry shaders are
> done, since they work completely differently.
>
> Anyone want to chime in with opinions on non-Intel hardware?

All radeon hw that supports geometry shaders also supports GL 3.3.

Alex