De-tab and align comments in gl_texture_object

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Corey Richardson <corey@octayn.net>
Correct clamping of TEXTURE_{MAX, BASE}_LEVEL

Previously, if TEXTURE_IMMUTABLE_FORMAT was TRUE, the levels were allowed to
be set like usual, but ARB_texture_storage states:

> if TEXTURE_IMMUTABLE_FORMAT is TRUE, then level_base is clamped to the range
> [0, <levels> - 1] and level_max is then clamped to the range [level_base,
> <levels> - 1], where <levels> is the parameter passed the call to
> TexStorage* for the texture object

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Corey Richardson <corey@octayn.net>
i965: Delete the BATCH_LOCALS macro.

This hasn't done anything in a long time, and it's only used in a couple
places...which means we couldn't use it without doing a bunch of work
anyway.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
docs: Import 9.1.6 release notes, add news item.
docs: Add md5sums to 9.1.6 release notes
gallium: clarify shift behavior with shift count >= 32

Previously, nothing was said what happens with shift counts exceeding
bit width of the values to shift. In theory 3 behaviors are possible:
1) undefined (classic c definition)
2) just shift out all bits (so result is zero, or -1 potentially for ashr)
3) mask the shift count to bit width - 1
API's either require 3) or are ok with 1). In particular, GLSL (as well as a
couple uninteresting legacy GL extensions) is happy with undefined, whereas
both OpenCL and d3d10 require 3). Consequently, most hw also implements 3).
So, for simplicity we just specify that 3) is required rather than saying
undefined and then needing state trackers to work around it.
Also while here specify shift count as a vector, not scalar. As far as I
can tell this was a doc bug, neither state trackers nor drivers used scalar
shift count.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
tgsi: obey clarified shift behavior

c shifts are undefined for shift counts exceeding (or matching) bit width,
so need to apply a mask (on x86 it actually would usually probably work as
shifts do masking on int domain shifts - unless some auto-vectorizer would
come along at last as simd domain does not mask the shift count).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
gallivm: obey clarified shift behavior

llvm shifts are undefined for shift counts exceeding (or matching) bit width,
so need to apply a mask for the tgsi shift instructions.

v2: only use mask for the tgsi shift instructions, not for the build shift
helpers. None of the internal callers need this behavior, and while llvm can
optimize away the masking for constants there are legitimate cases where it
might not be able to do so even if we know that shift count must be smaller
than type width (currently all such callers do not use the build shift
helpers).

Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
glsl: Change do_set_program_inouts' is_fragment_shader arg to shader_type.

This will allow us to add geometry shader support without having to
add another boolean argument.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Move count_attribute_slots() out of the linker and into glsl_type.

Our previous justification for leaving this function out of glsl_type
was that it implemented counting rules that were specific to GLSL
1.50.  However, these counting rules also describe the number of
varying slots that Mesa will assign to a varying in the absence of
varying packing.  That's useful to be able to compute from outside of
the linker code (a future patch will use it from
ir_set_program_inouts.cpp).  So go ahead and move it to glsl_type.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Expand count_attribute_slots() to cover structs.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Use count_attribute_slots() in ir_set_program_inouts.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Extract marking functions from ir_set_program_inouts.

This patch extracts the functions mark_whole_variable() and
try_mark_partial_variable() from the ir_set_program_inouts visitor
functions.  This will make the code easier to follow when we add
geometry shader support.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Fallback gracefully if ir_set_program_inouts sees unexpected indexing.

The code in ir_set_program_inouts that marks just a portion of a
variable as used (rather than the whole variable) only works on a few
kinds of indexing operations:

- Indexing into matrices
- Indexing into arrays of matrices, vectors, or scalars.

Fortunately these are the only kinds of indexing operations that we
expect to see; everything else is either handled by a
previously-executed lowering pass or prohibited by GLSL.

However, that could conceivably change in the future (the GLSL rules
might change, or we might modify the lowering passes).  To avoid
mysterious bugs in the future, let's have ir_set_program_inouts report
an assertion failure if it ever encounters an unexpected kind of
indexing operation (and in release builds, fall back to just marking
the whole variable as used).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: In ir_set_program_inouts, handle indexing outside array/matrix bounds.

According to GLSL, indexing into an array or matrix with an
out-of-range constant results in a compile error.  However, indexing
with an out-of-range value that isn't constant merely results in
undefined results.

Since optimization passes (e.g. loop unrolling) can convert
non-constant array indices into constant array indices, it's possible
that ir_set_program_inouts will encounter a constant array index that
is out of range; if this happens, just mark the whole array as used.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Modify ir_set_program_inouts to handle geometry shaders.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl/linker: Make update_array_sizes apply to just uniforms.

Commit 586b4b5 (glsl: Also update implicit sizes of varyings at link
time) extended update_array_sizes() to apply to both uniforms and
shader ins/outs.  However, doing creates problems for geometry
shaders, because update_array_sizes() assumes that variables with
matching names in different parts of the pipeline should have the same
sizes.  With the addition of geometry shaders, this is no longer true
(e.g. both vertex and geometry shaders have a gl_ClipDistance output
variable, but there's no reason these variables should have the same
sizes).

The original reason for commit 586b4b5 (avoid problems with
gl_TexCoord being 0 length) has since been addressed by commit 6f53921
(linker: Ensure that unsized arrays have a size after linking).  So go
ahead and switch update_array_sizes() back to only acting on uniforms.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Add EXT_texture_array support for geometry shaders.

We can't just use a ".glsl" file since the Lod variants are only
available in vertex and geometry shaders, while the bias variants are
only available in the fragment shader.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
main: Fix geometry shader error messages (missing right paren)

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
main: Allow for the possibility of GL 3.2 without ARB_geometry_shader4.

Previously, we assumed that the only way Mesa would expose geometry
shader support was via the ARB_geometry_shader4 extension.  But this
extension has some extra complications over GL 3.2 (interactions with
compatibility-only features, and link-time initialization of the
constant gl_VerticesIn).  So we want to allow for the possibility of
supporting GL 3.2 (with GLSL 1.50 style geometry shaders) even if
ctx->Extensions.ARB_geometry_shader4 is false.

This patch adds a new function, _mesa_has_geometry_shaders(), which
returns true if either ARB_geometry_shader4 is supported or the GL
version is at least 3.2 desktop.  Since compute_version() only enables
GL 3.2 functionality when GLSL 1.50 support is present, a sufficient
way for a back-end to advertise geometry shader support is to set
ctx->Const.GLSLVersion >= 150.

v2: Remove unnecessary ctx->Const.GeometryShaders150 constant.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>