mesa: Rename ArrayObj to VAO and DefaultArrayObj to DefaultVAO.

When reading through the Mesa drawing code, it's not immediately obvious
to me that "ArrayObj" (gl_array_object) is the Vertex Array Object (VAO)
state.  The comment above the structure explains this, but readers still
have to remember this and translate accordingly.

Out of context, "array object" is a fairly vague.  Even in context,
"array" has a lot of meanings: glDrawArrays, vertex data stored in user
arrays, gl_client_arrays, gl_vertex_attrib_arrays, and so on.

Using the term "VAO" immediately associates these fields with the OpenGL
concept, clarifying the situation and aiding programmer sanity.

Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
  -e 's/ArrayObj;/VAO;/g'                  \
  -e 's/->ArrayObj/->VAO/g'                \
  -e 's/Array\.ArrayObj/Array.VAO/g'       \
  -e 's/Array\.DefaultArrayObj/Array.DefaultVAO/g'

v2: Rerun command to resolve conflicts with Ian's meta patches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Rename "arrayObj" local variables to "vao".

Now that the field is named "VAO" instead of "ArrayObj", it makes sense
to call the local variables "vao" instead of "arrayObj".

Completely generated by:
$ find . -type f -print0 | xargs 0 sed -i 's/arrayObj/vao/g'

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Rename "struct gl_array_object" to gl_vertex_array_object.

I considered replacing it with "gl_vao", but spelling it out seemed to
fit better with Mesa's traditional style.  Mesa doesn't shy away from
long type names - consider gl_transform_feedback_object,
gl_fragment_program_state, gl_uniform_buffer_binding, and so on.

Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
  's/gl_array_object/gl_vertex_array_object/g'

v2: Rerun command to resolve conflicts with Ian's meta patches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Rename _mesa_..._array_obj functions to _mesa_..._vao.

_mesa_update_vao_client_arrays() is less of a mouthful than
_mesa_update_array_object_client_arrays(), and generally clearer.

Generated by:
$ find . -type f -print0 | xargs -0 sed -i \
  's/_mesa_\([^_]*\)_array_object/_mesa_\1_vao/g'
with manual whitespace and indentation fixes applied.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Rename _mesa_lookup_arrayobj to _mesa_lookup_vao.

For consistency with the previous renames.

Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
  's/_mesa_lookup_arrayobj/_mesa_lookup_vao/g'

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Rename ElementArrayBufferObj to IndexBufferObj.

DirectX and most hardware documentation use the term "Index Buffer" to
refer to a buffer containing indexes into arrays of vertex data, which
allows random access to vertex data, rather than sequential access.

OpenGL uses a different term for this concept: "Element Array Buffer".
However, "Index Buffer" has become much more widespread.  A quick
Google search shows 29,300 hits for "Element Array Buffer" vs.
82,300 hits for "Index Buffer."

Arguably, "Index Buffer" is clearer: an "element of an array" (or list)
usually refers to an actual item stored in the array, not the index used
to refer to it.

The terminology is also already used in Mesa: some VBO module code for
dealing with ElementArrayBufferObj names local variables "ib".

Completely generated by:
$ find . -type f -print0 | xargs -0 sed -i \
  's/ElementArrayBufferObj/IndexBufferObj/g'

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Update some comments relating to VAOs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Remove "APPLE" from some VAO error messages.

Chances are, people will be using the core names these days.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Drop unnecessary (void) ctx from VAO code.

ctx is always used, even on release builds.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
gallivm: fix opcode and function nesting

gallivm soa code supported only a single level of nesting for
control flow opcodes (if, switch, loops...) but the d3d10 spec
clearly states that those are nested within functions. To support
nesting of conditionals inside functions we need to store the
nesting data inside function contexts and keep a stack of those.
Furthermore we make sure that if nesting for subroutines is deeper
than 32 then we simply ignore all subsequent 'call' invocations.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
svga: refactor some shader code

Put common code in new svga_shader.c file.  Considate separate vertex/
fragment shader ID generation.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
svga: check shader size against max command buffer size

If the shader is too large, plug in a dummy shader.  This patch also
reworks the existing dummy shader code.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
gallium/auxiliary/indices: replace free() with FREE()

To match the CALLOC_STRUCT() call.

Cc: "10.0, 10.1" <mesa-stable@lists.freedesktop.org>

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
mesa: change GL_ALL_ATTRIB_BITS to 0xFFFFFFFF

This has been wrong for many years.  It was originally 0x000FFFFF and long
ago there was discussion about whether GL_ALL_ATTRIB_BITS should include
the then-new GL_MULTISAMPLE_BIT bit.  Eventually the ARB decided that
glPushAttrib(GL_ALL_ATTRIB_BITS) should save all current and future
attribute groups (hence ~0).  Unfortunately, Mesa's gl.h was never updated.

This was just recently spotted by Eric Anholt and reported as a bug to the
ARB.  Ian, Jon Leech and I discussed it at the ARB meeting and decided to
change Mesa's value to reflect the ARB's decision.

Acked-by: Eric Anholt <eric@anholt.net>
draw: fix incorrect color of flat-shaded clipped lines

When we clipped a line weren't copying the provoking vertex
color to the second vertex.  We also weren't checking for
first vs. last provoking vertex.

Fixes failures found with the new piglit line-flat-clip-color test.

Cc: "10.0, 10.1" <mesa-stable@lists.freedesktop.org>

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
docs: Add release notes for 10.0.3

Which was just made.
freedreno/a3xx: remove useless reg tracking in disasm-a3xx

Not really used for anything anymore.  So strip it out and avoid
conflicting symbols with upcoming new-compiler.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a3xx/compiler: prepare for new compiler

Shuffle things around to prepare for new compiler.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a3xx/compiler: split out old compiler

For the time being, keep old compiler as fallback for things that the
new compiler does not support yet.  Split out as it's own commit to make
the later new-compiler commits easier to follow.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a3xx/compiler: new compiler

The new compiler generates a dependency graph of instructions, including
a few meta-instructions to handle PHI and preserve some extra
information needed for register assignment, etc.

The depth pass assigned a weight/depth to each node (based on sum of
instruction cycles of a given node and all it's dependent nodes), which
is used to schedule instructions.  The scheduling takes into account the
minimum number of cycles/slots between dependent instructions, etc.
Which was something that could not be handled properly with the original
compiler (which was more of a naive TGSI translator than an actual
compiler).

The register assignment is currently split out as a standalone pass.  I
expect that it will be replaced at some point, once I figure out what to
do about relative addressing (which is currently the only thing that
should cause fallback to old compiler).

There are a couple new debug options for FD_MESA_DEBUG env var:

  optmsgs - enable debug prints in optimizer
  optdump - dump instruction graph in .dot format, for example:

http://people.freedesktop.org/~robclark/a3xx/frag-0000.dot.png
http://people.freedesktop.org/~robclark/a3xx/frag-0000.dot

At this point, thanks to proper handling of instruction scheduling, the
new compiler fixes a lot of things that were broken before, and does not
appear to break anything that was working before[1].  So even though it
is not finished, it seems useful to merge it in it's current state.

[1] Not merged in this commit, because I'm not sure if it really belongs
in mesa tree, but the following commit implements a simple shader
emulator, which I've used to compare the output of the new compiler to
the original compiler (ie. run it on all the TGSI shaders dumped out via
ST_DEBUG=tgsi with various games/apps):

https://github.com/freedreno/mesa/commit/163b6306b1660e05ece2f00d264a8393d99b6f12

Signed-off-by: Rob Clark <robclark@freedesktop.org>