Comment by mattst88 | Hacker News Reader

Comment by mattst88 | Hacker News Reader

Another Intel employee here (don't know the author). I work on Intel's Open Source OpenGL driver, which is part of Mesa. Most of the work I do is on our GLSL compiler and Gen hardware backend.

I've never used VTune (but it looks very cool) and some of the notation is different from what I'm used to.

If you're using an Intel GPU made in the last 10 years on Linux, the environment variable INTEL_DEBUG will allow you to see the disassembled shaders for a given program. Try "INTEL_DEBUG=fs,vs glxgears" to see the fragment and vertex shaders' assembly and the dumps of some intermediate representations along the way.

The Gen (or i965, as we call it) instruction set is really powerful, but does take a while to understand fully.

I've actually been trying to finish up an article about some tricks we do in the i965_dri.so driver (think bit twiddling hacks, but each using some interesting features of the instruction set). I'm curious if there's interest in such a thing. I'd probably be more motivated to finish it. :)

There is definitely interest in this. It is always nice to dive into different computing architectures and see how stuff is done. And it's never wrong to write something more accessible than the Intel manuals ;) (one can read those if really necessary anyhow)

What's the reason for generating 2 versions of each fragment shader (SIMD8 and SIMD16)?

That's a good question.

SIMD8/SIMD16 refers to the number of fragments processed per thread invocation. There is some overhead to spawning a thread, and so processing 16 fragments at a time is typically faster even though the shader itself is doing more work.

The driver provides both versions because it's the GPU that decides which version is use and where, even using both versions to shade the same primitive. For instance, on a triangle boundary maybe only 4 or 8 fragments are "lit", so the hardware spawns a SIMD8 thread and saves itself a little work.

SIMD16 shaders typically use twice the number of registers as SIMD8, and if they require registers to be spilled to memory it's likely the SIMD8 shader is faster even with the additional thread-spawning overhead. Lots of compiler optimization revolves around trying to squeak in under the register limit to get the program compiled as SIMD16 without spilling. :)

Reply on news.ycombinator.com