i965: rename legacy gs structs and functions to ff_gs.

"ff" is for "fixed function".  This frees up the name "gs" to refer to
user-defined geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Rename user-defined gs structs from vec4_gs to gs.

Now that the name "gs" is no longer used to refer to the legacy fixed
function geometry shaders, we can use it to refer to user-defined
geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Move vec4 register allocation data structures to brw->vec4.

This will avoid confusion when we add geometry shaders, since these
data structures will be shared by vertex and geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/gs: Update defines related to GS surface organization.

Defines that previously referred to VS now refer to VEC4, since they
will be shared by the user-programmable vertex shader and geometry
shader stages.

Defines that previously referred to the Gen6 geometry shader stage
(which is only used for transform feedback) are now renamed to
explicitly refer to Gen6, to avoid confusion with the Gen7
user-programmable geometry shader stage.

Based on work by Eric Anholt <eric@anholt.net>.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Move data from brw->vs into a base class if gs will also need it.

This paves the way for sharing the code that will set up the vertex
and geometry shader pipeline state.

v2: Rename the base class to brw_stage_state.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/gs: Create brw_context::gs structure to track GS program state.

v2: Change name from "vec4_gs" to simply "gs".

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Make CACHE_NEW_GS_PROG.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/gs: Allocate URB space for use by GS.

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".

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen7: Emit CS stall after 3DSTATE_PUSH_CONSTANT_ALLOC_PS.

This is required by the internal hardware docs and the PRM.  Probably
the reason we were getting away with not doing it was because we only
emitted 3DSTATE_PUSH_CONSTANT_ALLOC_PS during startup.  However that's
going to change with the introduction of geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: Allocate push constant space for use by GS.

Previously, we would always use the same push constant allocation
regardless of what shader programs were being run: the available push
constant space was split into 2 equal size partitions, one for the
vertex shader, and one for the fragment shader.

Now that we are adding geometry shader support, we need to do
something smarter.  This patch adjusts things so that when a geometry
shader is in use, we split the available push constant space into 3
nearly-equal size partitions instead of 2.

Since the push constant allocation is now affected by GL state, it can
no longer be set up by brw_upload_initial_gpu_state(); instead it must
be set up by a state atom.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Make sure constants re-sent after constant buffer reallocation.

The hardware requires that after constant buffers for a stage are
allocated using a 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS}
command, and prior to execution of a 3DPRIMITIVE, the corresponding
stage's constant buffers must be reprogrammed using a
3DSTATE_CONSTANT_{VS,HS,DS,GS,PS} command.

Previously we didn't need to worry about this, because we only
programmed 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS} once on
startup (or, previous to that, whenever BRW_NEW_CONTEXT was flagged).
But now that we reallocate the constant buffers whenever geometry
shaders are switched on and off, we need to make sure the constant
buffers are reprogrammed.

We do this by adding a new bit, BRW_NEW_PUSH_CONSTANT_ALLOCATION, to
brw->state.dirty.brw.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: generalize brw_vs_pull_constants in preparation for GS.

v2: Use GLbitfield instead of GLbitfield64 in
brw_upload_vec4_pull_constants.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: generalize brw_vs_binding_table in preparation for GS.

v2: Use GLbitfield instead of GLbitfield64 in
brw_vec4_upload_binding_table.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: Implement support for geometry shader surfaces.

This patch implements pull constant upload, binding table upload, and
surface setup for geometry shaders, by re-using vertex shader code
that was generalized in previous patches.

Based on work by Eric Anholt <eric@anholt.net>.

v2: Update ditry bits for brw_gs_ubo_surfaces to account for commit
77d8fbc (mesa: add & use a new driver flag for UBO updates instead of
_NEW_BUFFER_OBJECT).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: make the state atom for compiling Gen7 geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

v2: Use "unsigned" rather than "GLuint".
i965/vs: generalize gen6_vs_push_constants in preparation for GS.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Modify signature to update_texture_surface functions.

Previously these functions would accept a pointer to the binding table
and an index indicating which entry in the binding table should be
updated.  Now they merely take a pointer to the binding table entry to
be updated.

This will make it easier to generalize brw_texture_surfaces to support
geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: generalize brw_texture_surfaces in preparation for gs.

There is a slight functionality change.  Previously we would compute a
common value for num_samplers for all stages, and populate that many
entries in each stage's surf_offset table regardless of how many
samplers each stage used.  Now we only populate the number of entries
in the surf_offset table corresponding to the number of samplers
actually used by the stage.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: add geometry shader support to brw_texture_surfaces.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: Implement support for geometry shader samplers.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>