On Mon, Jul 22, 2013 at 1:42 PM, Paul Berry <stereotype...@gmail.com> wrote: > On 21 July 2013 23:14, Ian Romanick <i...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
