i965/vec4: Reswizzle sources when necessary.

Despite the comment above the function claiming otherwise, the function
did not reswizzle sources, which would lead to bad code generation since
commit 04895f5c, which began claiming we could do such swizzling when we
could not.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82932
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 1ee1d8ab468cafd25cfcc513319f3f046492947f)
mesa: Document SYSTEM_VALUE_VERTEX_ID and SYSTEM_VALUE_INSTANCE_ID

v2: Additions to the documentation for SYSTEM_VALUE_VERTEX_ID.  Quote
the GL_ARB_shader_draw_parameters spec and mention DirectX SV_VertexID.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit 9afb5ae8cae4460b87a5c03da3955f2e83434430)
mesa: Add SYSTEM_VALUE_VERTEX_ID_ZERO_BASE

There exists hardware, such as i965, that does not implement the OpenGL
semantic for gl_VertexID.  Instead, that hardware does not include the
value of basevertex in the gl_VertexID value.
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE is the system value that represents
this semantic.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit 5964a4f344fa4fd631bcccf67c065b9e66b94108)
mesa: Add SYSTEM_VALUE_BASE_VERTEX

This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related functions.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit 1e87fbd78f15f262b3dd2cbc16099e9f484c42a0)
glsl/linker: Make get_main_function_signature public

The next patch will use this function in a different file.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit 04d3323d4b7b7cae4954d80946f0ca202770dd14)
glsl: Add a lowering pass for gl_VertexID

Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA
is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed
by SYSTEM_VALUE_BASE_VERTEX.

v2: Put the enum in struct gl_constants and propoerly resolve the scope
in C++ code.  Fix suggested by Marek.

v3: Reabase on Matt's foreach_in_list changes (was using foreach_list).

v4 (Ken): Use a systemvalue instead of a uniform because
STATE_BASE_VERTEX has been removed.

v5: Use a boolean to select lowering, and only allow one lowering
method.  Suggested by Ken.

v6 (Ken): Replace strcmp against literal "gl_BaseVertex"/"gl_VertexID"
with SYSTEM_VALUE enum checks, for efficiency.

v7: Rebase on context constant initialization work.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit ec08b5e768271aa100be87c1ca6dd2b0109049d9)
mesa: Replace string comparisons with SYSTEM_VALUE enum checks.

This is more efficient.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 26c9514155bfcd1cf2cfeb2cfdb5d4b78a8072b0)
mesa: Fix glGetActiveAttribute for gl_VertexID when lowered.

The lower_vertex_id pass converts uses of the gl_VertexID system value
to the gl_BaseVertex and gl_VertexIDMESA system values.  Since
gl_VertexID is no longer accessed, it would not be considered active.

Of course, it should be, since the shader uses gl_VertexID.

v2: Move the var->name dereference past the var != NULL check.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 26e949b26effe741f9792e3efcba31c7209f3465)
i965: Handle SYSTEM_VALUE_VERTEX_ID_ZERO_BASE

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 9975792abd8be891bbe7245cb1d5c347dff65465)
i965: Calculate start/base_vertex_location after preparing vertices.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit c89306983c07e5a88c0d636267e5ccf263cb4213)
i965: Make gl_BaseVertex available in a buffer object.

This will be used for GL_ARB_shader_draw_parameters, as well as fixing
gl_VertexID, which is supposed to include gl_BaseVertex's value.

For indirect draws, we simply point at the indirect buffer; for normal
draws, we upload the value via the upload buffer.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit fdbabf22e183d478cd076215052fa877b125629b)
i965: Refactor Gen4-7 VERTEX_BUFFER_STATE emission into a helper.

We'll need to emit another VERTEX_BUFFER_STATE for gl_BaseVertex;
pulling this into a helper function will save us from having to deal
with cross-generation differences in that code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 87b10c4a7161905e3a9dc2b2ddc77fbf6908ebd5)
i965: Expose gl_BaseVertex via a vertex attribute.

Now that we have the data available, we need to expose it to the
shaders.  We can reuse the same vertex element that we use for
gl_VertexID, but we need to back it by an actual vertex buffer.

A hardware restriction requires that vertex attributes coming from a
buffer (STORE_SRC) must come before any other types (i.e. STORE_0).
So, we have to make gl_BaseVertex be the .x component of the vertex
attribute.  This means moving gl_VertexID to a different component.

I chose to move gl_VertexID and gl_InstanceID to the .z and .w
components, respectively, to make room for gl_BaseInstance in the .y
component (which would also come from a buffer, and therefore be
STORE_SRC).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit fbb353bc13a8924f9c6cd8c2572d299e3c4b9162)
i965: Request lowering gl_VertexID

Fixes the (new) piglit tests gles-3.0-drawarrays-vertexid,
gl-3.0-multidrawarrays-vertexid, and gl-3.2-basevertex-vertexid.

Fixes gles3conform failure in:

ES3-CTS.gtf.GL3Tests.transform_feedback.transform_feedback_vertex_id

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80247
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 927f5db46135b3eb63f401833b1e40a3be9ca4e0)
i965: Fix reference counting in new basevertex upload code.

In the non-indirect draw case, we call intel_upload_data to upload
gl_BaseVertex.  It makes brw->draw.draw_params_bo point to the upload
buffer, and increments the upload BO reference count.

So, we need to unreference it when making brw->draw.draw_params_bo point
at something else, or else we'll retain a reference to stale upload
buffers and hold on to them forever.

This also means that the indirect case should increment the reference
count on the indirect draw buffer when making brw->draw.draw_params_bo
point at it.  That way, both paths increment the reference count, so
we can safely unreference it every time.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit e980fe607155c79ccba56ef78854093b7730bef6)
i965: Separate gl_InstanceID and gl_VertexID uploading.

We always uploaded them together, mostly out of laziness - both required
an additional vertex element.  However, gl_VertexID now also requires an
additional vertex buffer for storing gl_BaseVertex; for non-indirect
draws this also means uploading (a small amount of) data.  This is extra
overhead we don't need if the shader only uses gl_InstanceID.

In particular, our clear shaders currently use gl_InstanceID for doing
layered clears, but don't need gl_VertexID.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 6b6145204dd4a1112f6e1fe10162636141495b79)
i965: Disable guardband clipping in the smaller-than-viewport case.

Apparently guardband clipping doesn't work like we thought: objects
entirely outside fthe guardband are trivially rejected, regardless of
their relation to the viewport.  Normally, the guardband is larger than
the viewport, so this is not a problem.  However, when the viewport is
larger than the guardband, this means that we would discard primitives
which were wholly outside of the guardband, but still visible.

We always program the guardband to 8K x 8K to enforce the restriction
that the screenspace bounding box of a single triangle must be no more
than 8K x 8K.  So, if the viewport is larger than that, we need to
disable guardband clipping.

Fixes ES3 conformance tests:
- framebuffer_blit_functionality_negative_height_blit
- framebuffer_blit_functionality_negative_width_blit
- framebuffer_blit_functionality_negative_dimensions_blit
- framebuffer_blit_functionality_magnifying_blit
- framebuffer_blit_functionality_multisampled_to_singlesampled_blit

v2: Mention the acronym expansion for TA/TR/MC in the comments.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
(cherry picked from commit 0bac2551e40410e2251daf4fd9faf69310ab34ce)
i965: Skip allocating UNIFORM file storage for uniforms of size 0.

Samplers take up zero slots and therefore don't exist in the params
array, nor are they included in stage_prog_data->nr_params.  There's no
need to store their size in param_size, as it's only used for dealing
with arrays of "real" uniforms (ones uploaded as shader constants).

We run into all kinds of problems trying to refer to the uniform storage
for variables that don't have uniform storage.  For one, we may use some
other variable's index, or access out of bounds in arrays.  In the FS
backend, our extra 2 * MaxSamplerImageUnits params for texture rectangle
rescaling paper over a lot of problems.  In the VS backend, we claim
samplers take up a slot, which also papers over problems.

Instead, just skip allocating storage for variables that don't have any.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2408f166db1d81f2e9cc86b3f413ddba5ba537fa)
i965/vec4: Make type_size() return 0 for samplers.

The FS backend has always used 0, and the VS backend has always used 1.
I think 1 is just working around other problems, and is incorrect.
Samplers are baked in; nothing uses the UNIFORM register we would
create, and we shouldn't upload any constant values for them.

Fixes ES3-CTS.shaders.struct.uniform.sampler_array_vertex.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7865026c04f6cc36dc81f993bc32ddda2806ecb5)
glsl: Speed up constant folding for swizzles.

ir_rvalue::constant_expression_value() recursively walks down an IR
tree, attempting to reduce it to a single constant value.  This is
useful when you want to know whether a variable has a constant
expression value at all, and if so, what it is.

The constant folding optimization pass attempts to replace rvalues with
their constant expression value from the bottom up.  That way, we can
optimize subexpressions, and ideally stop as soon as we find a
non-constant subexpression.

In order to obtain the actual value of an expression, the optimization
pass calls constant_expression_value().  But it should only do so if it
knows the value can be combined into a constant.  Otherwise, at each
step of walking back up the tree, it will walk down the tree again, only
to discover what it already knew: it isn't constant.

We properly avoided this call for ir_expression nodes, but not for
ir_swizzle nodes.  This patch fixes that, drastically reducing compile
times on certain shaders where tree grafting has given us huge
expression trees.  It also fixes SuperTuxKart.

Thanks to Iago and Mike for help in tracking this down.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78468
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>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 84a40ce86b1010873b194eb9bf0b8744234b829c)