[Mesa-dev] a newbie asking newbie questions

[Eric Anholt]

"Rogovin, Kevin" <kevin.rogovin at intel.com> writes:

> Hello all,
>
> I am new to Mesa development (and in particular the i965 driver). I am
> currently trying to gain an understanding of Mesa's implementation
> with mostly an eye on (just) the i965 driver. Some questions:
>
> There are some docs in docs, how up to date are those documents? In
> particular I saw this: ( from User Topics/Shading Language on the side
> bar)
>
>
> a.  Shading language programs are compiled into low-level programs
> very similar to those of GL_ARB_vertex/fragment_program.  b.  All
> vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
> float[4] registers.  c.  Float constants and variables are packed so
> that up to four floats can occupy one program parameter/register.  d.
> All function calls are inlined.  e.  Shaders which use too many
> registers will not compile.  f.  The quality of generated code is
> pretty good, register usage is fair.  g.  Shader error detection and
> reporting of errors (InfoLog) is not very good yet.  h.  The
> ftransform() function doesn't necessarily match the results of
> fixed-function transformation.
>
> My questions are:
>
> 1.  for item (a), I thought Mesa was using a custom IR that sorted of
> looked like LISP, is that correct? Is (a) even correct? For that
> matter where does the assembly style shader magicks fit in? [even
> though the asm interface is old, it is used in common user-oriented
> games, like Doom3 for example]. Additionally, there are extensions out
> there that update the asm interface for GL3 and GL4 features. Are
> those extensions already implemented in Mesa?

It doesn't particularly "look like" a language, because you don't ever
store text of it except for the builtin functions library (which is
about to change).  It's a tree-structured IR, with all the types you
know from GLSL (vec2s, for example).  This makes certain types of
pattern matching easy (min(max(a, 0), 1) -> saturate(a), for example),
but makes a bunch of other things hard (def/use chain tracking).

The assembly shaders get put into the same driver backend compiler
infrastructure, see brw_fs_fp.cpp (asm shaders) and brw_fs_visitor.cpp
(glsl shaders).

> disclaimer: I am quite *new* so some of my starting points might be
> utterly wrong. My understanding of the i965 so far is that it strongly
> prefers to work with SIMD commands (I guess operating on vec4's
> typically). One idea is that compiling of fragment shaders would break
> all operations down to scalar operations and then the shader would be
> re-assembled to process 4 fragments at a time by "combining" the
> shader commands of 4 fragments from 4 scalar ops into one vec4 op. Is
> this already done? [I have memory of seeing a slide from Ian R. that
> the i965 driver draws 8(or was it 4) pixels "at a time"].

It's not a preference question.  The registers are 8 floats wide.
Vertex shaders get invoked 2 vertices at a time, with a register
containing these values:

.   +------+------+------+------+------+------+------+------+
.   | v0.x | v0.y | v0.z | v0.w | v1.x | v1.y | v1.z | v1.w |
.   +------+------+------+------+------+------+------+------+

while these 8 pixels in screen space:

.   +----+----+----+----+
.   | p0 | p1 | p2 | p3 |
.   +----+----+----+----+
.   | p4 | p5 | p6 | p7 |
.   +----+----+----+----+

are loaded in fragment shader registers as:

.   +------+------+------+------+------+------+------+------+
.   | p0.x | p1.x | p4.x | p5.x | p2.x | p3.x | p6.x | p7.x |
.   +------+------+------+------+------+------+------+------+

Note how one register just holds a single channel ('.x' here) of a
vector.  A vec4 would take up 4 registers, and to do value0.xyzw *
value1.xyzw, you'd emit 4 MULs.

I suppose you could go out of your way to move things around such that
you made it work like the vertex shader did, but it would be a massive
overhead for no win.  The fragment shader mode is ideal, unless you're
only lighting up a couple of pixels.

To see how this ends up working in practice, I'd recommend looking at
some similar shader code between the VS and FS (perhaps from some piglit
tests?) under INTEL_DEBUG=vs,fs.

(You'll also find references to "16-wide" dispatch.  That's a mode where
you make each channel take up 2 registers of 8 pixels each, and the HW
decodes each instruction as an operation on both registers)

> 3.  related to (d), but not exactly the same: how are branches related
> to (non-unrollable) loops handled? in particular nested loops?

We have structured control flow all the way down to the hardware,
because the hardware handles the divergent control flow when one pixel
takes on side of an "if" and another pixel takes the other.  (And loops,
too).

> There is also some doxygen stuff found in doxygen, some of it (for
> example glapi.doxy) seems to being suffering from bit rot (for
> glapi.doxy it points to a directory that does not even exist
> anymore).

Nobody regularly generates doxygen output.  I'd like to set it up to
automatically run and post on fd.o some day, but it's low on the TODO
list.

> On a related note, where are the beans about the dispatch
> table?

I don't know this one (or particularly what you're asking, I guess).

> Also, is src/mesa/state_tracker part of Mesa main or Gallium stuff?
> Taking a quick, non-careful look, it looks like state tracking is
> handled by bits running around in mesa/main, is that correct?

That's the mesa to gallium translation layer.  It's the equivalent of
drivers/dri/whatever.

> What is the general rule of thumb of code that belongs in mesa/main vs
> further down to the drivers/dri/XXX (for me XXX-i965).

If it's shared by many drivers, let's get it into core so we can
actually share it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130916/c01188a5/attachment.pgp>