i965/vec4: Allow for dispatch_grf_start_reg to vary.

Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).

For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first register available for push constants in vertex
shaders.

For geometry shaders, we'll need the flexibility to set
dispatch_grf_start_reg to different values depending on the behvaiour
of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to
set it to 2 to allow the primitive ID to be delivered to the thread in
R1.

This patch eliminates the assumption that dispatch_grf_start_reg is
always 1.  In vec4_visitor, we record the regnum that was passed to
vec4_visitor::setup_uniforms() in prog_data for later use.  In
vec4_generator, we consult this value when converting an abstract
UNIFORM register to a concrete hardware register.  And in the code
that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the
value recorded in prog_data.

This will allow us to set dispatch_grf_start_reg to the appropriate
value when compiling geometry shaders.  Vertex shaders will continue
to always use a dispatch_grf_start_reg of 1.

v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/vec4: Virtualize setup_payload instead of setup_attributes.

When I initially generaized the vec4_visitor class in preparation for
geometry shaders, I assumed that the setup_attributes() function would
need to be different between vertex and geometry shaders, but its
caller, setup_payload(), could be shared.  So I made
setup_attributes() a virtual function.

It turns out this isn't true; setup_payload() needs to be different
too, since the geometry shader payload sometimes includes an extra
register (primitive ID) that has to come before uniforms.

So setup_payload() needs to be the virtual function instead of
setup_attributes().

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add brw->geometry_program.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add a case to brwBindProgram() for geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Create structs for use by GS program compilation.

v2: Make id "unsigned" rather than "GLuint".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add a case to brwNewProgram() for geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Combine 4 boolean args of brw_urb_WRITE into a flags bitfield.

The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we
have to add more flags to support geometry shaders anyhow.

Also plumb these flags through brw_clip_emit_vue(),
brw_set_urb_message(), and the vec4_instruction class.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add GS_OPCODE_URB_WRITE.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add GS_OPCODE_THREAD_END.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add GS_OPCODE_SET_DWORD_2_IMMED.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: add GS visitors.

This patch introduces the vec4_gs_visitor class, which translates
geometry shaders from GLSL IR to back-end opcodes.

This class is derived from vec4_visitor (which is also the base class
for vec4_vs_visitor), so as a result most of the back end code is
shared.  The only parts that differ are:

- Geometry shaders use a different input payload organization, since
  the inputs need to match up with the outputs of the previous
  pipeline stage (vec4_gs_visitor::setup_payload() and
  vec4_gs_visitor::setup_varying_inputs()).

- Geometry shader input array dereferences need a special stride
  computation, since all geometry shader inputs are interleaved into
  one giant array (vec4_gs_visitor::compute_array_stride()).

- There are no geometry shader system values
  (vec4_gs_visitor::make_reg_for_system_value()).

- At the beginning of a geometry shader, extra data in R0 needs to be
  zeroed out, and a vertex counter needs to be initialized
  (vec4_gs_visitor::emit_prolog()).

- When EmitVertex() appears in the shader, the current contents of
  output variables need to be emitted to the URB, and the vertex
  counter needs to be incremented
  (vec4_gs_visitor::visit(ir_emit_vertex *)).

- When generating a URB_WRITE message to output vertex data, the
  current state of the vertex counter needs to be used to store a
  write offset in the message header
  (vec4_gs_visitor::emit_urb_write_header()).

- The URB_WRITE message that outputs vertex data needs to be sent
  using GS_OPCODE_URB_WRITE, since VS_OPCODE_URB_WRITE would overwrite
  the offsets in the message header
  (vec4_gs_visitor::emit_urb_write_opcode()).

- At the end of a geometry shader, the final vertex count needs to be
  delivered using a URB WRITE message
  (vec4_gs_visitor::emit_thread_end()).

- EndPrimitive() functionality is not implemented yet
  (vec4_gs_visitor::visit(ir_end_primitive *)).

- There is no support for assembly shaders
  (vec4_gs_visitor::emit_program_code()).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Make prim_to_hw_prim accessible outside brw_draw.c.

We will need access to this array in order to configure the geometry
shader.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/vec4: Make a function for setting up vec4 program key clip info.

This functionality will need to be reused by geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Add a data structure for tracking VS output VUE map.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/gs: Create brw_context::vec4_gs structure to track GS program state.
i965/gs: Support UBOs by generating surface state and binding tables.

All but two of the piglit GLSL 1.50/uniform_buffer tests work, and
maxuniformblocksize and referenced-by-shader work.

v2 (Paul Berry <stereotype441@gmail.com>): Account for Ken's recent
binding table re-work.  Use brw->vec4_gs.bind_bo_offset instead of
brw->gs.bind_bo_offset.
i965/gs: make the state atom for compiling Gen7 geometry shaders.

v2: Use "unsigned" rather than "GLuint".
i965/gs: Allocate URB space for use by geometry shader.

Previously, we gave all of the URB space (other than the small amount
that is used for push constants) to the vertex shader.  However, when
a geometry shader is active, we need to divide it up between the
vertex and geometry shaders.

The size of the URB entries for the vertex and geometry shaders can
vary dramatically from one shader to the next.  So it doesn't make
sense to simply split the available space in two.  In particular:

- On Ivy Bridge GT1, this would not leave enough space for the worst
  case geometry shader, which requires 64k of URB space.

- Due to hardware-imposed limits on the maximum number of URB entries,
  sometimes a given shader stage will only be capable of using a small
  amount of URB space.  When this happens, it may make sense to
  allocate substantially less than half of the available space to that
  stage.

Our algorithm for dividing space between the two stages is to first
compute (a) the minimum amount of URB space that each stage needs in
order to function properly, and (b) the amount of additional URB space
that each stage "wants" (i.e. that it would be capable of making use
of).  If the total amount of space available is not enough to satisfy
needs + wants, then each stage's "wants" amount is scaled back by the
same factor in order to fit.

When only a vertex shader is active, this algorithm produces
equivalent results to the old algorithm (if the vertex shader stage
can make use of all the available URB space, we assign all the space
to it; if it can't, we let it use as much as it can).

In the future, when we need to support tessellation control and
tessellation evaluation pipeline stages, it should be straightforward
to expand this algorithm to cover them.

v2: Use "unsigned" rather than "GLuint".