[Mesa-dev] GLSL IR representation of EmitVertex
maraeo at gmail.com
Fri Aug 19 01:31:09 PDT 2011
On Fri, Aug 19, 2011 at 8:42 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 08/18/2011 12:02 PM, Vincent Lejeune wrote:
>> I would like to have several opinions about the implementation (on the frontend side) of EmitVertex() function.
>> Prototype of the function is :
>> void EmitVertex();
>> It is only available when writing Geometry Shader Code, it acts as a beacon saying the GPU to generate a vertex according to gl_Position/gl_FrontColor,... defined at the time of calling.
>> The syntax of EmitVertex is the syntax of a function and is recognised as such by the parser, which is fine. However having it considered as a function when building GLSL high level tree is more problematic :
>> At link stage all function calls are currently inlined, but EmitVertex has no body. This would requires to add lots of guards statements all over optimisations/lowering passes, which is not the most elegant solution IMHO.
>> Builtins function are mostly wrapper around operators, which allow to have them parsed as functions and transparently emitted as native hardware opcode later.
>> Such a solution would need to add some "0 operator" that can be passed to an ir_expression*. If this solution might work, it is unsafe on the semantic side of things : Operators are meant to "operate" on something and above all, expressions are rvalue that might be reordered whereas EmitVertex is a side effect function and not an rvalue.
>> A third solution is to have another ir_* node type in ir.h to reflect the specificities of the EmitVertex function (and might be used for RestartPrimitive as well). This is the most safe solution on the long term but it is likely to break stuff at early developement step : adding another node has impact in the overall compiling/linking process.
> Hi Vincent,
> I believe the best way to implement this is your third suggestion: add a
> new ir_emit_vertex instruction:
> class ir_emit_vertex : public ir_instruction
> Then, the built-in code would simply be:
> (function EmitVertex
> (signature void
> This would involve adding a certain amount of boilerplate---cloning,
> visitor and hierarchical visitor support, as well as IR printer and
> reader support. But it's not that bad.
> EmitVertex() is definitely _not_ an expression, as expressions by
> definition represent some value (or computation resulting in a value).
> We also can't treat it as a special empty-bodied function, as there are
> other such built-ins. For example, geometry shaders also provide void
> EndPrimitive(), and tesselation shaders provide void barrier().
> That said, geometry shaders represent a huge amount of effort...even
> once the compiler support is in place, adding the backend support is by
> no means trivial. I believe GLSL 1.30 is required as well, so it might
> be worth waiting until we hit that milestone (as well as GL 3.0). I
> might suggest working on a simpler project first...
FWIW the Draw module (a software vertex processing module in Gallium)
has partial geometry shader support already, as well as the Gallium
interface and TGSI. It's mainly the GLSL compiler part that is
More information about the mesa-dev