<div dir="ltr">On 21 July 2013 23:14, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On 07/19/2013 11:48 AM, Paul Berry wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (TL;DR: geometry shaders are humming along, but because of a hitch I've<br> run into, I'm going to change gears and implement GLSL 1.50-style<br> geometry shaders first rather than ARB_geometry_shader4 functionality.<br> This means some piglit tests will need to be rewritten).<br> <br> Hello all--<br> <br> As some of you may have noticed, I've spent the last several weeks<br> writing a number of geometry shader tests and fixinging my "gs" branch<br> (on <a href="https://github.com/stereotype441/mesa.git" target="_blank">https://github.com/<u></u>stereotype441/mesa.git</a>). I'm happy to report<br> that it's working better than ever: I now have the following features<br> working in geometry shaders on Intel drivers:<br> <br> - Texturing.<br> - Built-in uniform variables.<br> - Interactions with ARB_shader_texture_lod,<br> ARB_shading_language_packing, ARB_texture_cube_map_array,<br> ARB_texture_multisample, ARB_texture_rectangle,<br> ARB_uniform_buffer_object, and EXT_texture_array.<br> - Mixing user-defined geometry shaders with fixed-function fragment shaders.<br> - gl_PointSizeIn, gl_PrimitiveIDIn, gl_PrimitiveID, gl_ClipVertex,<br> gl_ClipDistanceIn, and gl_ClipDistance (including several important<br> corner cases of gl_ClipDistance that were previously broken, such as<br> bulk assignment).<br> - Color clamping.<br> <br> I've done all of this work using the ARB_geometry_shader4 version of<br> geometry shaders; my intention was to get that working first, then<br> introduce additional code to support GLSL 1.50-style geometry shaders.<br> This was partly motivated by the fact that Bryan Cain's initial work on<br> geometry shaders was done using ARB_geometry_shader4, and partly<br> motivated by the fact that it's our standard development practice in<br> Mesa to develop features as extensions first, and then only support a<br> core feature once all of the extensions it includes have been finished.<br> However, I've now run into hitch that's making me want to change course<br> and implement GLSL-1.50 style geometry shaders first. It's a bit of a<br> long story so buckle up:<br> <br> In GLSL 1.50, the way you specify the input primitive type for a<br> geometry shader is using a layout qualifier in the shader source code,<br> so it is known at compile time. Whereas in ARB_geometry_shader4, the<br> way you specify the input primitive type is using<br> glProgramParameteriARB() prior to linking. This means that the input<br> primitive type isn't known at compile time.<br> <br> That's a problem because ARB_geometry_shader4 provides for a read-only<br> built-in constant called gl_VerticesIn, which is the number of vertices<br> in each geometry shader input primitive (e.g. if the input primitive<br> type is "triangles", gl_VerticesIn is 3). Mesa does not currently<br> support constants whose value is determined at link time, since constant<br> folding, determination of explicit array sizes, and a lot of<br> constant-related error checking happen at compile time. To work around<br> this, the "gs" branch currently treats gl_VerticesIn as a varying input<br> during compilation, and then at link time replaces any references to it<br> with the appropriate constant value.<br> </blockquote> <br></div></div> Oh dear. That's... awful.<br> <br> 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).<br> </blockquote><div><br></div><div>Huh, interesting idea. I can't decide if it would be any better either. It's certainly worth keeping in mind.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Before committing to this route we should:<br> <br> 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.<br></blockquote><div><br></div>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.<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> 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.<br></blockquote><div><br></div><div>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.<br> <br></div><div>Anyone want to chime in with opinions on non-Intel hardware?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Just going for 3.2 and punting on the extension for now seems like the right way to go, but I also don't want to paint ourselves into a "we have to rearchitect the world" kind of corner. :(<br></blockquote> <div><br></div><div>I don't mind if someone wants to do some research in the background on questions 1 and 2 above, but IMHO we can safely proceed with this plan even without that information. In all likelihood, the only thing we're going to learn by answering questions 1 and 2 is whether we need to implement both GLSL 1.50 and ARB_geometry_shader4, or just GLSL 1.50. So in either case it makes sense to work on GLSL 1.50 first. In the unlikely event that we run into another snag down the road and need to switch back to ARB_geometry_shader4, we can always pick up where we left off--I've archived the state of my "gs" branch in "gs-arb".<br> </div></div></div></div>