radeonsi: Implement PIPE_QUERY_TIMESTAMP

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Reviewed-by: Marek Olšák <maraeo@gmail.com>

gallivm: fix min/mag switchover point for nearest/none mip filter

Previously, the min/mag switchover point when using nearest/none mip
filter was effectively -0.5 which can't be right. Looks like new OpenGL
thinks it's ok if it's always 0.0 (older versions required 0.5 in some
cases), let's hope everybody else thinks that's fine too.
Refactor this slightly and get the per-quad/per-pixel min/mag decision
values further down to sampling, though still only the first component
is used yet.
While here also fix code trying to skip lod bias application etc. when
mipfilter is none, as this is still needed for determining min/mag filter.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallium/osmesa: Link, not copy, the shared library to the LIB_DIR.

Just like all other mesa libraries...

CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

gallium/osmesa: Always link with the c++ linker.

Just like all other gallium targets...

CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

gallium/osmesa: Make and install an osmesa.pc.

As of "2f142d59 build: Add --enable-gallium-osmesa flag." the pkgconfig
file from classic osmesa is no longer installed when building gallium
osmesa, so copy it to gallium osmesa and install the copy instead.

CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/gs: Add a data structure for tracking VS output VUE map.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.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()).

v2: Make num_input_vertices const.  Refer to registers as rN rather
than gN, for consistency with the PRM.  Fix misspelling.  Improve
comment in the ir_emit_vertex visitor explaining why we emit vertices
inside a conditional.  Enclose the conditional code in the
ir_emit_vertex visitor between curly braces.

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

i965/gs: Add GS_OPCODE_SET_DWORD_2_IMMED.

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

i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT.

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

i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET.

v2: Added a comment to vec4_generator::generate_gs_set_write_offset().

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

i965/gs: Add GS_OPCODE_THREAD_END.

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

i965/gs: Add GS_OPCODE_URB_WRITE.

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

i965/gs: Add a flag allowing URB write messages to use a per-slot offset.

This will be used by geometry shaders to implement the EmitVertex()
function, since it requires writing data to a dynamically-determined
offset within the geometry shader's URB entry.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/gs: Add a case to brwNewProgram() for geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/gs: Add a case to brwBindProgram() for geometry shaders.

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

i965/gs: Add brw->geometry_program.

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

i965/vec4: Virtualize setup_payload instead of setup_attributes.

When I initially generalized 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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

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>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}.

This patch moves the following things into brw_vec4.{cpp,h}:

- struct brw_vec4_compile
- struct brw_vec4_prog_key
- brw_vec4_prog_data_compare()
- brw_vec4_prog_data_free()

This will allow us to avoid having to include brw_vs.h in
geometry-shader-specific files.

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

i965: Make brw_{shader,vec4}.h safe to include from C.

The patch that follows will move the definition of struct
brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for
brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct
brw_vs_prog_key, which contains brw_vec4_prog_key as a member).  Since
brw_vs.h is included from C source files, that means that brw_vec4.h
will need to be safe to include from C.  Same for brw_shader.h, since
it is included by brw_vec4.h.

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

i965: Stop including brw_vs.h from brw_vec4.h.

This is backwards from what we are going to want in the long term, which is:

- brw_vec4.h declares general-purpose vec4 infrastructure needed by
  both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.

Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.

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

i965: Initialize all elements of ctx->ShaderCompilerOptions.

Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance as an input or output) will fail to work.

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

i965: Make brw_{program,vs}.h safe to include from C++.

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

mesa/program: Make prog_instruction.h and program.h safe to include from C++.

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

glsl: Refactor handling of gl_ClipDistance/gl_ClipVertex linkage rules for GS.

This patch extracts the following logic from
validate_vertex_shader_executable():

(a) Generate an error if the shader writes to both gl_ClipDistance and
    gl_ClipVertex.

(b) Record whether the shader writes to gl_ClipDistance in
    gl_shader_program for use by the back-end.

(c) Record the size of gl_ClipDistance in gl_shader_program for use by
    transform feedback logic.

And moves it into a function that is shared between vertex and
geometry shaders.

Strictly speaking we only need to have shared logic for (b) and (c)
right now (since (a) only matters in compatibility contexts, and we're
only implementing geometry shaders in core contexts right now).  But
the three are closely related enough that it seems sensible to keep
them together.

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

mesa: Fix assertion error with glDebugMessageControl

enums were being converted twice resulting in incorrect values.
The extra conversion has been removed and the redundant assert is
removed also.

Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>

mesa: Specify a better GL_MAX_SERVER_WAIT_TIMEOUT limit.

The previous value of (GLuint64) ~0 has some problems:

GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has
to be queried via GetInteger64v(), which returns a GLint64.  This means
that some applications are likely to treat it as a signed integer, where
~0 means -1.  Negative values are nonsensical and problematic.

When interpreted correctly, ~0 translates to about 0.58 million years,
which seems rather excessive.

This patch changes it to 0x1fff7fffffff, which is about 1.11 years.
This is still plenty long, and is the same as both an int64 and uint64.
Applications that accidentally store it in a 32-bit int/unsigned also
get a non-negative value, which is again the same as both int and
unsigned.  This value was suggested by Ian Romanick.

v2: Add the ULL prefix on the constant (suggested by Ian).

Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org

meta: Set correct viewport and projection in decompress_texture_image.

_mesa_meta_begin() sets up an orthographic project and initializes the
viewport based on the current drawbuffer's width and height.  This is
likely the window size, since it occurs before the meta operation binds
any temporary buffers.

decompress_texture_image needs the viewport to be the size of the image
it's trying to draw.  Otherwise, it may only draw part of the image.

v2: Actually set the projection properly too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68250
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mak Nazecic-Andrlon <owlberteinstein@gmail.com>

i965: Fix misapplication of gles3 srgb workaround

Fixes inconsistent failure of gles2conform/GL2Tests/glUniform/glUniform.test
under gnome-shell. What follows is a description of the bug and its fix.

When intel_update_renderbuffers() allocates a miptree for a winsys
renderbuffer, it propagates the renderbuffer's format to become also the
miptree's format.

If the winsys color buffer format is SARGB, then, in the first call to
eglMakeCurrent, intel_gles3_srgb_workaround() changes the renderbuffer's
format to ARGB. That is, it changes the format from sRGB to non-sRGB.
However, it changes the renderbuffer's format *after*
intel_update_renderbuffers() has allocated the renderbuffer's miptree.
Therefore, when eglMakeCurrent returns, the miptree format (SARGB)
differs from the renderbuffer format (ARGB).

If the X server reallocates the color buffer,
intel_update_renderbuffers() will create a new miptree for the
renderbuffer. The new miptree's format (ARGB) will differ from old
miptree's format (SARGB). This mismatch between old and new miptrees
causes bugs.

Fix the bug by moving intel_gles3_srgb_workaround() to occur *before*
intel_update_renderbuffers().

CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67934
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

gallivm: do per-element lod for lod bias and explicit derivs too

Except for explicit derivs with cube maps which are very bogus anyway.
Just like explicit lod this is only used if no_quad_lod is set in
GALLIVM_DEBUG env var.
Minification is terrible on cpus which don't support true vector shifts
(but should work correctly). Cannot do the min/mag filter decision (if
they are different) per pixel though, only selecting different mip levels
works.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: (trivial) fix int/uint border color clamping

Just a copy & paste error.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=68409.
Note that the test passing before probably simply means it doesn't verify
clamping of the border color itself as required by the OpenGL spec.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: (trivial) fix linear aos sampling of 3d compressed formats

block size depth is always 1 even for compressed formats (unless someone
invents true 3d compressed formats at least which we can't represent).
Nearest (and soa) path had it right.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

radeonsi: Fix y/z/w component values of TGSI_SEMANTIC_FOG pixel shader inputs

They are defined as constant 0.0/0.0/1.0.

Three more little piglits.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

gallium: Support PIPE_FORMAT_R10G10B10A2_UINT.

Same as PIPE_FORMAT_B10G10R10A2_UINT but without the swizzling.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

trace: Handle null tokens.

Used for example on stream out without geometry shader.

ilo: do not need last shader stage for 3DSTATE_SBE

We have set up 3DSTATE_SBE (or 3DSTATE_SF on GEN6) in
ilo_shader_select_kernel_routing().  There is no need to pass the last shader
stage to the GPE function.

ilo: fix a potential issue with STATE_SIP

Command length is ORed to the wrong place.  Since the ORed value is zero,
there is no real change.

ilo: add GEN check to 3DSTATE_CLIP

Assert that gen6_emit_3DSTATE_CLIP is for GEN 6 and 7.

build: Add --enable-gallium-osmesa flag.

The Gallium implementation is apparently not ready for regular
consumption, so as much as I hate adding more build-time options, here's
another.

Acked-by: Brian Paul <brianp@vmware.com>

glsl: Give a warning, not an error, for UBO qualifiers on non-matrices.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59648
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>

glsl: Remove ubo_qualifiers_allowed variable.

No longer used.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: Drop duplicate error messages.

This same message is printed in the validate_matrix_layout_for_type
function.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: Rename ubo_qualifiers_valid to ubo_qualifiers_allowed.

The variable means that UBO qualifiers are allowed in a particular
context (e.g., not allowed in a struct field declaration), rather than a
particular set of UBO qualifiers are valid.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/fs: Add code to print out global copy propagation sets.

This was invaluable when debugging the global copy propagation
algorithm.  We may as well commit it in case someone needs to print
out the sets in the future.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

osmesa: Symlink shared library to LIB_DIR

Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Tested-by: Brian Paul <brianp at vmware.com>
Reviewed-by: Brian Paul <brianp at vmware.com>

svga: minor clean-ups in emit_hw_vs_vdecl()

gallivm: unify sin and cos implementation

The (complicated!) math is all identical, there's just minimal differences how
sign bit is calculated plus there's an additional subtraction for the argument
going into the polynomial for cos.
The logic stays 100% the same (with a small exception, sign bit calculation for
sin is minimally simplified, applying sign mask after xoring the arguments
instead of applying it to each argument).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: add comment for bogus min/mag filter selection with nearest mip filter

Detected this hunting some other bug, not sure if it really needs fixing but
it is definitely wrong.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: fix rho calculation for 1d case

Was using wrong (undefined) vector element (the elements are at 0/2 position,
not 0/1).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

i965/gen7: Set MOCS L3 cacheability for IVB/BYT (v2)

IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
so let's make use of it.

pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most
other things show less gains/no regressions, except furmark which
loses some 10 points.

I didn't have a BYT at hand for testing.

v2: Don't check (brw->gen == 7) in gen7 functions. (chadv)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

i965/hsw: Populate MOCS for STATE_BASE_ADDRESS (v2)

Just spotted these unpopulated MOCS fields when comparing the code
against BSpec. Set the MOCS to the same as everywhere else in Haswell:
L3-cacheable.

v2: Annotate state packet fields (chadv).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

glapi/gen: build temporary files in the build directory

Writing to the source directory can cause multiple parallel builds
from the same source to fail. Create the temporary files in the
build directory.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

mesa: Never advertise _S3TC compressed formats

The NVIDIA driver doesn't expose them, and piglit's
arb_texture_compression-invalid-formats expects them to not be there.

This, with the previous commit, fixes piglit
arb_texture_compression-invalid-formats.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

mesa: Only advertise GL_ETC1_RGB8_OES in ES contexts

There is no extension for this format in desktop GL, so an application
can't give the format back to glCompressedTexImage2D.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Track existence of default float precision in GLSL ES fragment shaders

This is required by the spec, and it's a bit tricky because the default
precision is scoped.  As a result, I'm slightly abusing the symbol
table.

Fixes piglit no-default-float-precision.frag tests and the piglit
default-precision-nested-scope-0[1234].frag tests that are currently on
the piglit mailing list for review.

On IRC I got confirmation from cwabbot that ARM (Mali T6xx and T400)
enforces this requirement and from kusma that NVIDIA (Tegra2) enforces
this requirement.  We should be safe from regressing shipping
applications.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Merge precision qualifiers too

We never noticed this before because we previously didn't enfoce GLSL ES
fragement shader requirements that precision be defined.  There may also
have been some interaction here with the addition of
GL_ARB_shading_language_420pack, but it doesn't appear to me that it
added any new bugs (just perhaps uncovered some old ones).

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Pass type to is_valid_default_precision_type instead of name

This is used by the next patch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

vdpau/decode: Fix comment.

Reviewed-by: Christian König <christian.koenig@amd.com>

vl/query: Only support VDP_CHROMA_TYPE_420 for 12 bit formats.

Reviewed-by: Christian König <christian.koenig@amd.com>

util: add avx2 and xop detection to cpu detection code

Going to need this soon (not going to bother with avx2 intrinsics at this time
but don't want to do workarounds for true vector shifts if llvm itself can use
them just fine and won't need the gazillion instruction emulation).
Not really tested other than my cpu returns 0 for these features...
(I have no idea if llvm actually would emit avx2/xop instructions neither...)

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: fix bogus aos path detection

Need to check the wrap mode of the actually used coords not a fixed 2.
While checking more than necessary would only potentially disable aos and
not cause any harm I'm pretty sure for 3d textures it could have caused
assertion failures (if s,t coords have simple filter and r not).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: do clamping of border color correctly for all formats

Turns out it is actually very complicated to figure out what a format really
is wrt range, as using channel information for determining unorm/snorm etc.
doesn't work for a bunch of cases - namely compressed, subsampled, other.
Also while here add clamping for uint/sint as well - d3d10 doesn't actually
need this (can only use ld with these formats hence no border) and we could
do this outside the shader for GL easily (due to the fixed texture/sampler
relation) do it here too just so I can forget about it.

v2: move border color clamping out of fetch texel. Also change it to clamp
the whole border vector at once (and use vectorized load of border color),
which saves a couple of instructions - needs some different handling of
mixed signed/unsigned formats so skip the per channel stuff and just derive
this from first channel except for special formats.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: implement better control of per-quad/per-element/scalar lod

There's a new debug value used to disable per-quad lod optimizations
in fragment shader (ignored for vs/gs as the results are just too wrong
typically). Also trying to detect if a supplied lod value is really a
scalar (if it's coming from immediate or constant file) in which case
sampler code can use this to stay on per-quad-lod path (in fact for
explicit lod could simplify even further and use same lod for both
quads in the avx case but this is not implemented yet).
Still need to actually implement per-element lod bias (and derivatives),
and need to handle per-element lod in size queries.

v2: fix comments, prettify.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

mesa: use ARRAY_SIZE() macro instead of magic number

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

build: fix out-of-tree builds in gallium/auxiliary

The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory.  So,
create the directories just in case.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

radeonsi: Always pre-load separate VGPRs for centroid vs. center interpolation

The LLVM R600 backend currently always uses separate VGPRs for these.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68162
(Centroid interpolation is identical to center interpolation without
multisampling, so the shader hardware was only pre-loading one set of
interpolation coefficients, and the pixel shader code was using
uninitialized values as the centroid interpolation coefficients)

Cc: mesa-stable@lists.freedesktop.org
Tested-by: Laurent Carlier <lordheavym@gmail.com>

radeonsi: Fix SPI_BARYC_CNTL register initialization

The centroid / center interpolation related bits have different meanings
as of SI.

Fixes 7 centroid interpolation related piglit tests.

gallium/osmesa: add same checks to OSMesaMakeCurrent as the other osmesa

Fixes a opengl crash in wine.

Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>

gallium/osmesa: link against static libglapi library too to get the gl exports

This should fix missing symbols in a osmesa built against shared glapi
osmesa build. All opengl exports were missing that are defined in the
static glapi, so link against both to fix this.

I could swear I've done this before, maybe there was a glitch in the matrix.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47824
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>

i965: Shorten sampler loops in precompile key setup.

Now that we have the number of samplers available, we don't need to
iterate over all 16.  This should be particularly helpful for vertex
shaders.

v2: Use the correct shader program (caught by Paul Berry).

This needs to initialize the exact same set of sampler swizzles as
the actual key setup, or else we end up doing recompiles due to some
being XYZW and others being 0.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

ilo: add ILO_DEBUG=flush

When specified, ilo will print a line similar to

  cp flushed for render with 949+888 DWords (22.4%) because of frame end

for every ilo_cp_flush() call.

ilo: add ILO_DEBUG=draw

It can print out pipe_draw_info and the dirty bits set, useful for debugging.

r600g/sb: Move memsets of member structs to within constructor bodies.

Silences "Uninitialized pointer field" defects reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Vadim Girlin <vadimgirlin@gmail.com>

glsl: Use alignment of container record for its first field

The first field of a record in a UBO has the aligment of the record
itself.

Fixes piglit vs-struct-pad, fs-struct-pad, and (with the patch posted to
the piglit list that extends the test) layout-std140.

NOTE: The bit of strangeness with the version of visit_field without the
record_type poitner is because that method is pure virtual in the base
class.  The original implementation of the class did this to ensure
derived classes remembered to implement that flavor.  Now they can
implement either flavor but not both.  I don't know a C++ way to enforce
that.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68195
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org

glsl: Add new overload of program_resource_visitor::visit_field method

The outer-most record is passed into the visit_field method for
the first field.  In other words, in the following structure:

    struct S1 {
        vec4 v;
        float f;
    };

    struct S {
        S1 s1;
        S1 s2;
    };

    uniform Ubo {
        S s;
    };

s.s1.v would get record_type = S (because s1.v is the first non-record
field in S), and s.s2.v would get record_type = S1.  s.s1.f and s.s2.f
would get record_type = NULL becuase they aren't the first field of
anything.

This new overload isn't used yet, but the next patch will add several
uses.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org

glsl: Disallow embedded structure definitions

Continue to allow them in GLSL 1.10 because the spec allows it.
Generate an error in all other versions because the specs specifically
disallow it.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

meta: Add default precision qualifier to all fragement shaders

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Add default precision qualifiers for ES builtins

Once the compiler proplerly checks for default precision qualifiers,
these shaders will cease to compile.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>

glsl: Remove extra "types" from error message

Send it straight to the Department of Redundancy Department.

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

i965: Make the VS binding table as small as possible.

For some reason, we didn't use this information even though the VS
backend has computed it (albeit poorly) for ages.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/vs: Rework binding table size calculation.

Unlike the FS, the VS backend already computed the binding table size.
However, it did so poorly: after compilation, it looked to see if any
pull constants/textures/UBOs were in use, and set num_surfaces to the
maximum surface index for that category.  If the VS only used a single
texture or UBO, this overcounted by quite a bit.

The shader time surface was also noted at state upload time (during
drawing), not at compile time, which is inefficient.  I believe it also
had an off by one error.

This patch computes it accurately, while also simplifying the code.

It also renames num_surfaces to binding_table_size, since num_surfaces
wasn't actually the number of surfaces used.  For example, a VS that
used one UBO and no other surfaces would have set num_surfaces to
SURF_INDEX_VS_UBO(1) == 18, rather than 1.  A bit of a misnomer there.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/vs: Plumb brw_vec4_prog_data into vec4_generator().

This will be useful for the next commit.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Make the FS binding table as small as possible.

Computing the minimum size was easy, and done at compile-time for no
extra overhead here.  Making the binding table smaller wastes less batch
space.

Adding the CACHE_NEW_WM_PROG dirty bit isn't strictly necessary, since
other atoms depend on it and flag BRW_NEW_SURFACES.  However, it's best
to add it for clarity and safety.  It shouldn't add any new overhead.

v2: Use binding_table_size, rather than max_surface_index.

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

i965/fs: Track the binding table size in brw_wm_prog_data.

By tracking the maximum surface index used by the shader, we know just
how small we can make the binding table.

Since it depends entirely on the shader program, we can just compute
it once at compile time, rather than at binding table emit time (which
happens during drawing).

v2: Store binding_table_size, rather than max_surface_index, for
    consistency with the VS (which needs to be able to represent 0
    surfaces).

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

i965: Use SURF_INDEX_DRAW() for drawbuffer binding table indices.

SURF_INDEX_DRAW() has been the identity function since the dawn of time,
and both the shader code and binding table upload code relied on that,
simply using X rather than SURF_INDEX_DRAW(X).

Even if that continues to be true, using the macro clarifies the code.

The comment about draw buffers needing to be first in order for
headerless render target writes to work turned out to be wrong; with
this change, SURF_INDEX_DRAW can be changed to arbitrary indices and
everything continues working.

The confusion was over the "Render Target Index" field in the FB write
message header.  If it were a binding table index, then RT 0 would have
to be at index 0 for headerless FB writes to work.  However, it's
actually an index into the blend state table, so there's no problem.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Paul Berry <stereotype441@gmail.com>

i965: Shorten sampler loops in key setup.

Now that we have the number of samplers available, we don't need to
iterate over all 16.  This should be particularly helpful for vertex
shaders.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Make sampler counts available for the entire drawing operation.

Previously, we computed sampler counts when generating the SAMPLER_STATE
table.  By computing it earlier, we should be able to shorten a bunch of
loops.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Split the brw_samplers atom into separate FS/VS stages.

This allows us to avoid uploading the VS sampler state table if only the
fragment program changes.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Upload separate VS and FS sampler state tables.

Now, each shader stage has a sampler state table that only refers to the
samplers actually used by that problem.  This should make the VS table
non-existant or very small.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Make upload_sampler_state_table a virtual function.

This allows us to coalesce the brw_samplers and gen7_samplers atoms.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Upload separate per-stage sampler state tables.

Also upload separate sampler default/texture border color entries.

At the moment, this is completely idiotic: both tables contain exactly
the same contents, so we're simply wasting batch space and CPU time.

However, soon we'll only upload data for textures actually /used/ in
a particular stage, which will usually make the VS table empty and
very likely eliminate all redundancy.  This is just a stepping stone.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Un-hardcode border color table from update_sampler_state().

Like the previous patch, this simply pushes direct access to brw->wm up
one level in the call chain.  Rather than passing the whole array, we
just pass a pointer to the correct spot in the array, similar to what we
do for the actual sampler state structure.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Un-hardcode border color table from upload_default_color.

When we begin uploading separate sampler state tables for VS and FS,
we won't be able to use &brw->wm.sdc_offset[ss_index].  By passing it in
as a parameter, we push the problem up to the caller.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Split sampler count variable to be per-stage.

Currently, we only have a single sampler state table shared among all
stages, so we just copy wm.sampler_count into vs.sampler_count.

In the future, each shader stage will have its own SAMPLER_STATE table,
at which point we'll need these separate sampler counts.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Re-enable global copy propagation.

I believe the data flow analysis actually works now, and it should be
safe to re-enable global copy propagation.  It even does things now.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Fix computation of livein.

Since the initial value for livein is an overestimation (0xffffffff),
it's extremely likely that it will shrink, which means we can't simply
OR in new bits - we need to fully recompute it based on the current
liveout values.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>