vc4: Move shader record setup before the draw call.

The flush only happens after both are written, so we can do them in either
order.  This will let me compute max_index during the shader record setup.
vc4: Compute max_index instead of trusting the rest of userspace.

max_index was coming from either the user telling us as part of
glDrawRangeElements, or from an incidental calculation as part of some
sort of primitive conversion fallback.  Sometimes, it was just set to the
default "I don't know" ~0 value.

If it wasn't set to the actual max index, then the kernel would reject the
draw call for allowing out-of-bounds VBO reads.  So, compute the max index
from the sizes of the VBOs, which isn't too expensive (unlike mapping and
reading the index buffer) and is reliable.

Fixes piglit vao-element-array-buffer.
mesa: Remove some dead helper functions.

Dead since the _MaxElement removal, but these functions seemed generally
applicable, so I decided to remove them in a separate patch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Use proper structure for glGet*(GL_TEXTURE_COORD_ARRAY*).

The code in get.c that handles this uses ctx->Array.VAO->VertexAttrib,
which is a gl_vertex_attrib_array structure, not a gl_client_array.

The offsets of all fields happened to be the same in both structures, at
least on x86_64.  "Size," "Type," and "Stride" are obviously the same:
both structures start with the same fields, in the same order.

"Enabled" is dicier: there are different fields before it in both
structures, including pointer sized values which might need special
alignment.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
mesa: Set correct array element in vbo_exec_vtx_init.

I'm not familiar with this code, but this sure appears to be a typo.
It looks like the intent is to set each array element, not arrays[0]
each time.  Notably, the loop just below uses "array", not "arrays".

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
mesa: Use VertexArray, not _VertexArray, in array size expressions.

Both sizes are VERT_ATTRIB_MAX, so this has no effect.  But it drops a
few trivial uses of the derived state.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
i965: Set JumpCount, not JIP, on ENDIF on Gen 6.

Despite what the Sandybridge PRM says, ENDIF has Jump Count in <dst>,
not JIP in <src1>. (The same mistake appears about WHILE as well).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/sf: Disable instruction compaction.

Currently a no-op, since instruction compaction isn't implemented for the
generations that have a programmable strips-and-fans unit.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/compaction: Rework 3-src compaction logic.

It may be possible to create a contrived example in which a 3-src
instruction would have been compacted on Gen < 8. I'd rather not
discover it in the wild.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/compaction: Don't set UIP on ELSE on Gen < 8.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/compaction: Remove unnecessary is-compacted? check.

Used to pass over previously compacted instructions in this loop, but no
longer. No point in checking.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Make src_offset local to the for loop.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Increment offset in for loop.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/compaction: Use sizeof brw_inst/brw_compact_inst.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Reduce size of compacted_counts[] array.

The array was previously indexed in units of brw_compact_inst (8-bytes),
but before compaction all instructions are uncompacted, so every odd
element was unused.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Add support for Gen5.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Add BRW_OPCODE_NENOP for G45.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Add support for G45.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965/compaction: Support compaction of control flow instructions.

We're currently emitting compactable control flow instruction the wrong
types, preventing their compaction. The next patch will fix this and
actually enable compaction.

On chips that cannot compact control flow instructions, attempts to find
a match in the datatype table will fail.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
i965: Emit ELSE/ENDIF JIP with type D on Gen 7.

The spec says the type must be W (JIP is 16-bits after all), but we've
been emitting it with a UD type all along and have experienced no
adverse effects. Changing the type to D allows ELSE and ENDIF
instructions to be compacted.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>