The goal of this page is to document some of the surprises in the Intel open-source GL implementation.
Generally things are categorized by the generation -- 830 meaning gen2 (830, 845, 855, 865), 915 meaning gen3 (915, 945, g33), and 965 meaning gen4+ (965, g45).
965: Dynamic branching unlikely to be a performance win.
GLSL added support for if, for, while, and other dynamic branching. This would encourage switching from the traditional way of doing it in the assembly shaders by running both sides of an if and using compares and multiplies to choose the result, to using a simple if statement. However, due to the way the fragment shader is architected, if not all the pixels in a dispatch group (generally 8 or 16 at a time) take the same branch of the shader, you end up executing both paths anyway. Additionally, due to limitations in the GLSL compiler, no optimization is performed on shaders with dynamic branching. This can be a 30% performance hit.
We hope to resolve this in the future.
965: No support for indices other than ~0 in ARB_primitive_restart
The hardware requires that 0xffffffff (or appropriately truncated for smaller size indices) be used to indicate a primitive restart. If an index other than ~0 is used to indicate primitive restart, it will fall back to doing primitive restart handling in software -- reading the index buffer and doing draw calls between the restarts.
915: Support for GLSL
The 915-class hardware doesn't support many of the features of GLSL, notably dynamic branching. However, GLSL is quite useful from a programmer's perspective even if some features of the language aren't available. So, we've added the "fragment_shader" driconf option that enables limited GLSL program execution support.
Among the features that don't work are if statements, non-unrolled for loops, subroutines, dFdx(), dFdy(), fwidth(), backface color, and noise().
Some of these should be fixed in the future, including flattening if statements to work, inlining more subroutines so they work, and backface color support.
Additionally, the 915-class hardware has no support for occlusion queries, which are a requirement for GL 1.5. There doesn't appear to be a way to emulate them that would be useful for application developers. However, most applications using GLSL shaders require GL 2.0, as the GL 2.0 entrypoints are simpler and very nice to use. To support running those applications, a debug driconf option called "stub_occlusion_query" is provided that enables nonconformant ARB_occlusion_query support, that in combination with the ARB_fragment_shader support results in the driver reporting GL 2.0 support.