tools/trace: Simple script to compare two traces.

Based on the earlier apitrace tracediff.sh script.

mesa: Silence GCC warning 'comparison between signed and unsigned integer expressions'

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Fix broken call to print_table_stats

The function takes a parameter, but none was given.  Also, in the
non-GET_DEBUG case, silence the unused parameter warning.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Set VertexProgram.MaxOutputComponents and FragmentProgram.MaxInputComponents in standalone scaffolding

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Allow several ARB_geometry_shader4 queries in OpenGL 3.2

GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS, GL_MAX_GEOMETRY_OUTPUT_VERTICES,
GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS, and
GL_MAX_GEOMETRY_UNIFORM_COMPONENTS all have the same enum value and
meaning as their _ARB counterparts.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Expose MAX_GEOMETRY_{INPUT,OUTPUT}_COMPONENTS on OpenGL 3.2

The comment '# GL 3.0 / GLES3' was incorrect.  The
MAX_VERTEX_OUTPUT_COMPONENTS and MAX_FRAGMENT_INPUT_COMPONENTS queries
were added in OpenGL 3.2 (with geometry shaders) and OpenGL ES 3.0.
This just fixes that comment.

v2: Add the GEOMETRY queries in the existing '# GL 3.2' section since
they have nothing to do with GLES3.  Suggested by Paul.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Get GL_MAX_FRAGMENT_INPUT_COMPONENTS from FragmentProgram.MaxInputComponents

In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16,
but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Get GL_MAX_VERTEX_OUTPUT_COMPONENTS from VertexProgram.MaxOutputComponents

In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16,
but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i915: Set VertexProgram.MaxOutputComponents and FragmentProgram.MaxInputComponents

This was the only remaining place in Mesa that sets MaxVaryings without
also setting these values.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Set *Program.Max{Input,Output}Components

Now that MaxVaryings is > 16, VertexProgram.MaxOutputComponents,
GeometryProgram.MaxInputComponents, GeometryProgram.MaxOutputComponents,
and FragmentProgram.MaxInputComponents also need to be set.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Paul Berry <stereotype441@gmail.com>

mesa: Set default values for Max{Input,Output}Components in init_program_limits

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Remove gl_constants::MaxVaryingComponents

There are no longer any users.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>

mesa: Use correct data for MAX_{VERTEX,GEOMETRY}_VARYING_COMPONENTS_ARB queries

Previously gl_constants::MaxVaryingComponents was used.  Now
gl_constants::VertexProgram::MaxOutputs and
gl_constants::GeometryProgram::MaxOutputs are used.

This means that st_extensions.c had to be updated to set these fields
instead of MaxVaryingComponents.  It was previously the only place that
set MaxVaryingComponents.

I believe that the structure is allocated by calloc, so the value should
be initialized to zero in non-Gallium drivers before and after my
change.  Right now nobody enables GL_ARB_geometry_shader4, so it's
pretty much dead code anyway.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>

mesa: Track per-stage shader input and output limits independently

In OpenGL 3.2 these are independently queryable.  In addition, the spec
has different minimum-maximums for various values.
GL_MAX_VERTEX_OUTPUT_COMPONENTS is 64, but
GL_MAX_GEOMETRY_OUTPUT_COMPONENTS (and GL_MAX_FRAGMENT_INPUT_COMPONENTS)
is 128.

In OpenGL ES 3.0 these are also independently queryable.  The spec has
different minimum-maximums for various values.
GL_MAX_VERTEX_OUTPUT_VECTORS is 16, but GL_MAX_FRAGMENT_INTPUT_VECTORS
is 15.

None of these values are used yet.  I have just added space to the
structures.  Future patches will add users and eventually remove some
old fields.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>

mesa: Support GL_MAX_VERTEX_OUTPUT_COMPONENTS query with ES3

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>

i965: Refactor Gen4-6 SURFACE_STATE setup for buffer surfaces.

This was an embarassingly large amount of copy and pasted code,
and it wasn't particularly simple code either.  By factoring it out
into a helper function, we consolidate the complexity.

v2: Properly NULL-check bo.  Caught by Eric Anholt.
v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather
    than making callers do it.  This makes the buffer_size parameter
    the actual size of the buffer.  Suggested by Paul Berry.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Refactor Gen7+ SURFACE_STATE setup for buffer surfaces.

This was an embarassingly large amount of copy and pasted code,
and it wasn't particularly simple code either.  By factoring it out
into a helper function, we consolidate the complexity.

v2: Properly NULL-check bo.  Caught by Eric Anholt.
v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather
    than making callers do it.  This makes the buffer_size parameter
    the actual size of the buffer.  Suggested by Paul Berry.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Fix off by one errors in texture buffer size calculations.

The value that's split into width/height/depth needs to be the size of
the buffer minus one.  This makes it consistent with the constant buffer
and shader time SURFACE_STATE setup code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Fix writemask != 0 assertions on Sandybridge.

This fixes myriads of regressions since commit 169f9c030c16d1247a3a7629
("i965: Add an assertion that writemask != NULL for non-ARFs.").

On Sandybridge, our control flow handling (such as brw_IF) does:

   brw_set_dest(p, insn, brw_imm_w(0));
   insn->bits1.branch_gen6.jump_count = 0;

This results in a IMM destination with zero for the writemask.  IMM
destinations are rather bizarre, but the code has been working for ages,
so I'm loathe to change it.

Fixes glxgears on Sandybridge.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

glsl: Delete builtin_builder::shader when destroying built-ins.

I would use _mesa_delete_shader, but it's declared static, and we don't
really need any of the stuff in it anyway.

This fixes a memory leak caught by Valgrind.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Fix brw_gs_prog_data_compare to actually check field members.

&a and &b are the address of the local stack variables, not the actual
structures.  Instead of comparing the fields of a and b, we compared
...some stack memory.

Not a candidate for stable since GS code doesn't exist in 9.2.

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

i965: Fix brw_vs_prog_data_compare to actually check field members.

&a and &b are the address of the local stack variables, not the actual
structures.  Instead of comparing the fields of a and b, we compared
...some stack memory.

Caught by Valgrind on Piglit's glsl-lod-bias test (among many others).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68233
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: mesa-stable@lists.freedesktop.org

i965: Move binding table code to a new file, brw_binding_tables.c.

The code to upload the binding tables for each stage was scattered
across brw_{vs,gs,wm}_surface_state.c and brw_misc_state.c, which also
contain a lot of code to populate individual SURFACE_STATE structures.

This patch brings all the binding table upload code together, and splits
it out from the code which fills in SURFACE_STATE entries.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Use brw_upload_binding_table() for the pixel shader as well.

This is not quite the same: brw_upload_binding_table() also has code to
early-return if there are no entries, while the existing code did not.

The PS binding table is unlikely to be empty since it will have at least
one color buffer.  If it ever is empty, early returning seems wise.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Generalize brw_vec4_upload_binding_table() beyond vec4 stages.

Instead of passing in a brw_vec4_prog_data structure, we can simply
pass the one field it needs: the number of entries in the binding table.

We also need to pass in the shader time surface index rather than
hardcoding SURF_INDEX_VEC4_SHADER_TIME.

Since the resulting function is stage-agnostic, this patch removes
"vec4_" from the name.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Convert loop to memcpy in brw_vec4_upload_binding_table().

This is probably more efficient.  At any rate, it's less code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Update comments in brw_vec4_upload_binding_table().

The first comment was a bit stale; there are more kinds of surfaces than
textures and pull constants.

The second was a leftover "to do" comment for something I already did.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

winsys/sw/xlib: fix compile error in xlib_sw_winsys.c.

xlib_sw_winsys.h:5:22: fatal error: X11/Xlib.h: No such file or directory

The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).

It appears the intent was to use X11_INCLUDES defined in configure.ac.

The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.

Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

glx: fix compile error in egl_glx.c.

egl_glx.c:40:22: fatal error: X11/Xlib.h: No such file or directory

The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).

It appears the intent was to use X11_INCLUDES defined in configure.ac.

The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.

Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

freedreno/a3xx: fix typo mixup w/ mipfilter

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: fix glReadPixels

duh, we still need to flush if there are pending draws and it isn't an
unsynchronized case.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

gallivm: adjust wrap mode to CLAMP_TO_EDGE always for cube maps.

Technically without seamless filtering enabled GL allows any wrap mode, which
made sense when supporting true borders (can get seamless effect with border
and CLAMP_TO_BORDER), but gallium doesn't support borders and d3d9 requires
wrap modes to be ignored and it's a pain to fix up the sampler state (as it
makes it texture dependent). It is difficult to imagine a situation where an
app really wants another behavior so just cheat here. (It looks like some
graphics hw (intel) actually requires this too hence it should be safe.)

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

android: Remove builtin_compiler

The first part was done in:

   commit c845140a20efa6a30a5465301d1f9b4acea79155
   Author: Kenneth Graunke <kenneth@whitecape.org>
   Date:   Tue Sep 3 21:22:17 2013 -0700

Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

util/u_blit: Implement util_blit_pixels via pipe_context::blit.

This removes a lot of code, but not everything, as util_blit_pixels_tex
is still useful when one needs to override pipe_sampler_view::swizzle_?.

Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

util/u_blit: Support blits from cubemaps.

By calling util_map_texcoords2d_onto_cubemap.

A new parameter for util_blit_pixels_tex is necessary, as
pipe_sampler_view::first_layer is always supposed to point to the first
face when sampling from cubemaps.

Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

vega: Use pipe_context::blit instead of util_blit_pixels_tex.

Only compile-tested but it seems straightforward.

Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

i965: Rename brw_{fs,vec4}_emit.cpp to brw_{fs,vec4}_generator.cpp.

The previous names were really confusing to talk about:
- brw_fs_visitor() contained methods named emit_whatever().
- brw_fs_generator() contained methods named generate_whatever(), but
  lived in brw_fs_emit.cpp.

So when someone said "the emit layer", or "emit code", we weren't sure
whether they meant the visitor's emit() functions or the generator in
brw_fs_emit.cpp.

By renaming these files, the method names, class names, and file names
all match, which is much less confusing.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>

glsl: Correctly validate fma()'s types.

lrp() can take a scalar as a third argument, and fma() cannot.

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

glsl: Add frexp signatures and implementation.

I initially implemented frexp() as an IR opcode with a lowering pass,
but since it returns a value and has an out-parameter, it would break
assumptions our optimization passes make about ir_expressions being pure
(i.e., having no side effects).

For example, if opt_tree_grafting encounters this code:

uniform float u;
void main()
{
  int exp;
  float f = frexp(u, out exp);
  float g = float(exp)/256.0;
  float h = float(exp) + 1.0;
  gl_FragColor = vec4(f, g, h, g + h);
}

it may try to optimize it to this:

uniform float u;
void main()
{
  int exp;
  float g = float(exp)/256.0;
  float h = float(exp) + 1.0;
  gl_FragColor = vec4(frexp(u, out exp), g, h, g + h);
}

Some hardware has an instruction which performs frexp(), but we would
need some other compiler infrastructure to be able to generate it, such
as an intrinsics system that would allow backends to emit specific code
for particular bits of IR.

Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Lower ldexp.

v2: Drop frexp lowering.
Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Add ldexp_to_arith lowering pass.

Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Allow vectors to be created from ir_constant().

Note the parameter name change in the int version of ir_constant, to
avoid the conflict with the loop iterator.

v2: Make analogous change to builtin_builder::imm().
Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Add support for ldexp.

v2: Drop frexp. Rebase on builtins rewrite.
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Add some missing bits to {mesa,brw,cache}_bits[].

These data structures are used for debug output, so it wasn't hurting
anything that there were missing bits.  But it's good to keep things
up to date.

This patch also adds static asserts so that the {brw,cache}_bits[]
arrays are the proper size, so that we don't forget to add to them in
the future.  Unfortunately there's no convenient way to assert that
mesa_bits[] is the proper size.

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

i965/gs: Implement basic gl_PrimitiveIDIn functionality.

If the geometry shader refers to the built-in variable
gl_PrimitiveIDIn, we need to set a bit in 3DSTATE_GS to tell the
hardware to dispatch primitive ID to r1, and we need to leave room for
it when allocating registers.

Note: this feature doesn't yet work properly when software primitive
restart is in use (the primitive ID counter will incorrectly reset
with each primitive restart, since software primitive restart works by
performing multiple draw calls).  I plan to address that in a future
patch series.

Fixes piglit test "spec/glsl-1.50/execution/geometry/primitive-id-in".

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

i965/gs: New gs primitive types are supported by HW primitive restart.

When we previously implemented primitive restart, we didn't add cases
to brw_primitive_restart.c's can_cut_index_handle_prims() for the
primitive types that are introduced with geometry shaders.  It turns
out that all of the new primitive types are supported by hardware
primitive restart.

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

i965/gs: Add new primitive types.

As part of its support for geometry shaders, GL 3.2 introduces four
new primitive types: GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY,
GL_TRIANGLES_ADJACENCY, and GL_TRIANGLE_STRIP_ADJACENCY.

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

gallivm: some bits of seamless cube filtering implementation

Simply adjust wrap mode to clamp_to_edge. This is all that's needed for a
correct implementation for nearest filtering, and it's way better than
using repeat wrap for instance for linear filtering (though obviously this
doesn't actually do seamless filtering).

v2: fix s/t wrap not r/s...

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

i965: Remove MIPLAYOUT_BELOW from Gen4-6 constant buffer surface state.

Specifying a miptree layout makes no sense for constant buffers.

This has no functional change since BRW_SURFACE_MIPMAPLAYOUT_BELOW is
just a #define for 0.

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

egl: Also add EGL_TEXTURE_FORMAT as a valid eglQueryWaylandBufferWL attribute

Now that we have a table of accepted eglQueryWaylandBufferWL() attributes,
we should also list EGL_TEXTURE_FORMAT.

egl: add EGL_WAYLAND_Y_INVERTED_WL attribute

This enables querying of wl_buffer's orientation

i965: Use gen7_upload_constant_state for 3DSTATE_CONSTANT_PS as well.

Now we use gen7_upload_constant_state() for all three shader stages.

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

i965: Set brw_stage_state::push_const_size for PS constants.

This paves the way for using gen7_upload_constant_state for PS data.

The formula is copied from gen7_wm_state.c.

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

i965: Introduce a prog_data temporary in gen6_upload_wm_push_constants.

This saves a bit of typing and shortens a few lines.

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

i965/gen6+: Support 128 varying components.

GL 3.2 requires us to support 128 varying components for geometry
shader outputs and fragment shader inputs, and 64 varying components
otherwise.  But there's no hardware limitation that restricts us to 64
varying components, and core Mesa doesn't currently allow different
stages to have different maximum values, so just go ahead and enable
128 varying components for all stages.  This gets us better test
coverage anyway.

Even though we are only working on GL 3.2 support for gen7 right now,
gen6 also supports 128 varying components, so go ahead and switch it
on there too.

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

i965/ff_gs: Generate URB writes using a loop.

Previously we only ever did 1 URB write, since the maximum number of
varyings we support is small enough to fit in 1 URB write (when using
BRW_URB_SWIZZLE_NONE, which is what the pre-Gen7 GS always uses).  But
we're about to increase the number of varying components we support
from 64 to 128.

With 128 varyings, the most URB writes we'll have to do is 2, but it's
just as easy to write a general-purpose loop.

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

i965/gen6: Fix assertions on VS/GS URB size.

The "{VS,GS} URB Entry Allocation Size" fields of 3DSTATE_URB allow
values in the range 0-4, but they are U8-1 fields, so the range of
possible allocation sizes is 1-5.  We were erroneously prohibiting a
size of 5.

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

i965/vec4: Generate URB writes using a loop.

Previously we only ever did 1 or 2 URB writes, since the maximum
number of varyings we support is small enough to fit in 2 URB writes.
But GL 3.2 requires the geometry shader to support 128 output varying
components, and this could require up to 3 URB writes.

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

i965/fs: When >64 input components, order them to match prev pipeline stage.

Since the SF/SBE stage is only capable of performing arbitrary
reorderings of 16 varying slots, we can't arrange the fragment shader
inputs in an arbitrary order if there are more than 16 input varying
slots in use.  We need to make sure that slots 16-31 match the
corresponding outputs of the previous pipeline stage.

The easiest way to accomplish this is to just make all varying slots
match up with the previous pipeline stage.

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

i965/fs: Simplify computation of key.input_slots_valid during precompile.

The for loop was rather silly.  In addition to checking brw->gen < 6
on each loop iteration, it took pains to exclude bits from
fp->Base.InputsRead that don't correspond to fragment shader inputs.
But those bits would never have been set in the first place, since the
only bits that are ever set in fp->Base.InputsRead are fragment shader
inputs.

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

i965/gs: Stop storing an input VUE map in the GS program key.

Now that the vertex shader output VUE map is determined solely by a
64-bit bitfield, we don't have to store it in its entirety in the
geometry shader program key; instead, we can just store the bitfield,
and let the geometry shader infer the VUE map at compile time.

This dramatically reduces the size of the geometry shader program key,
which we want to keep small since it gets recomputed whenever the
active program changes.

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

i965/gen6+: Remove VUE map dependency on userclip_active.

Previously, on Gen6+, we laid out the vertex (or geometry) shader VUE
map differently depending whether user clipping was active.  If it was
active, we put the clip distances in slots 2 and 3 (where the clipper
expects them); if it was inactive, we assigned them in the order of
the gl_varying_slot enum.

This made for unnecessary recompiles, since turning clipping on/off
for a shader that used gl_ClipDistance might rearrange the varyings.
It also required extra bookkeeping, since it required the user
clipping flag to be provided to brw_compute_vue_map() as a parameter.

With this patch, we always put clip distances at in slots 2 and 3 if
they are written to.  do_vs_prog() and do_gs_prog() are responsible
for ensuring that clip distances are written to when user clipping is
enabled (as do_vs_prog() previously did for gen4-5).

This makes the only input to brw_compute_vue_map() a bitfield of which
varyings the shader writes to, a fact that we'll take advantage of in
forthcoming patches.

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

i965/fs: Stop wasting input attribute space on gl_FragCoord and gl_FrontFacing.

Previously, if a fragment shader accessed gl_FragCoord or
gl_FrontFacing, we would assign them their own slots in the fragment
shader input attribute array, using up space that could be made
available to real varyings.  This was not strictly necessary (since
these values are not true varyings, and are instead computed from
other data available in the FS payload).  But we had to do it anyway
because the SF/SBE setup code assumed that every 1 bit in the
gl_program::InputsRead bitfield corresponded to a genuine varying
variable.

Now that the SF/SBE code consults brw_wm_prog_data and only sets up
the attributes that the fragment shader actually needs, we don't have
to do this anymore.

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

i965/sf: Consult brw_wm_prog_data when setting up SF/SBE state.

Previously, the SF/SBE setup code delivered varying inputs to the FS
in the order in which they appear in the gl_program::InputsRead
bitfield, since that's what the FS expects.

When we add support for more than 64 varying components, this will no
longer always be the case, because the Gen6+ SF/SBE stage is only
capable of performing arbitrary reorderings of 16 varying slots.  So,
when there are more than 16 vec4's worth of varying inputs, the FS
will have to adjust the order its input varyings in order to partially
match the order of outputs from the geometry or vertex shader.

To allow extra flexibility in the ordering of FS varyings, this patch
causes the SF/SBE to deliver varying inputs to the FS in exactly the
order that the FS requests, by consulting brw_wm_prog_data::urb_setup
and brw_wm_prog_data::num_varying_inputs.

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

i965/sf: Consolidate common code for setting up gen6-7 attribute overrides.

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

i965/sf: Use BRW_SF_URB_ENTRY_READ_OFFSET rather than hardcoded values.

We always program the SF unit to start reading the vertex URB entry at
offset 1.  In upcoming patches, we'll be adding FS code that relies on
this.  So consistently use the constant BRW_SF_URB_ENTRY_READ_OFFSET
rather than hardcoding a 1.

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

i965/fs: Consult brw_wm_prog_data::num_varying_inputs when setting up WM state.

Previously, we assumed that the number of varying inputs consumed by
the fragment shader was equal to the number of bits set in
gl_program::InputsRead.  However, we'll soon be making two changes
that will cause that not to be true:

- We'll stop wasting varying input space for gl_FragCoord and
  gl_FrontFacing, which aren't varyings.

- For fragment shaders that have more than 16 varying inputs, we'll
  adjust the layout of the inputs to account for the fact that the
  SF/SBE pipeline stage can't reorder inputs beyond the first 16; if
  there are GS outputs that the FS doens't use (or vice versa) this
  may cause the number of FS varying inputs to change.

So, instead of trying to guess the number of FS inputs from
gl_program::InputsRead, simply read it from
brw_wm_prog_data:num_varying_inputs, which is guaranteed to be correct
since it's populated by fs_visitor::calculate_urb_setup().

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

i965/fs: Change brw_wm_prog_data::urb_read_length to num_varying_inputs.

On gen4-5, the FS stage reads varying inputs from URB entries that
were output by the SF thread, where each register stores the
interpolation setup for two components of a vec4, therefore the FS
urb_read_length is twice the number of FS input varyings.  On gen6+,
varying inputs are directly deposited in the FS payload by the SF/SBE
fixed function logic, so urb_read_length is irrelevant.

However, in future patches, it will be nice to be able to consult
brw_wm_prog_data to determine how many varying inputs the FS expects
(rather than inferring it from gl_program::InputsRead).  So instead of
storing urb_read_length, we simply store num_varying_inputs in
brw_wm_prog_data.  On gen4-5, we multiply this by 2 to recover the URB
read length.

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

i965/fs: Expose "urb_setup" as part of brw_wm_prog_data.

At the moment, for Gen6+, the FS assumes that all varying inputs are
delivered to it in the order in which they appear in the
gl_program::InputsRead bitfield, and the SF/SBE setup code ensures
that they are delivered in this order.

When we add support for more than 64 varying components, this will no
longer always be possible, because the Gen6+ SF/SBE stage is only
capable of performing arbitrary reorderings of 16 varying slots.

To allow extra flexibility in the ordering of FS varyings, this patch
causes the FS to advertise exactly what ordering it expects.

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

ilo: make ilo_bind_sampler_states return void

So that it can be hooked up pipe_context::bind_sampler_states that is
currently living on another branch.

glsl/tests: Update .gitignore for new unit test.

I rarely run 'git status', so I failed to notice this was missing.

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

glsl/tests: Add a test for properties of sampler types.

For each sampler type, this tests that:
- The base type is GLSL_TYPE_SAMPLER.
- The dimensionality is set correctly.
- The returned data type is correct.
- The sampler_array and sampler_shadow flags are set correctly.
- sampler_coordinate_components() returns the correct value.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>

st/mesa: don't dereference stObj->pt if NULL

It seems a user app can get us into this state, I trigger the fail
running fbo-maxsize inside virgl, it fails to create the backing
storage for the texture object, but then segfaults here when it
should fail the completeness test.

Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

nouveau: fix regression since float comparison instructions (v2)

Fix the return type and allow src and dst types for comparison
to be separate, this at least fixes the two test cases I've written.

v2: drop the u32->s32 change

Acked-by: Christoph Bumiller <christoph.bumiller@speed.at>
Signed-off-by: Dave Airlie <airlied@redhat.com>

vdpau/decode: Check max width and max height.

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

freedreno: PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE

When the old contents do not need to be preserved, it is faster to
create a new backing bo rather than stall.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: fix VFD_INDEX_MAX overflow

max_index may be 0xffffffff.  The hardware does not need 1 + max_index
(although it does not hurt unless max_index wraps around to zero).

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: add debug option to disable GMEM bypass

Useful for debugging.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: handle front_ccw

Used by supertuxkart.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: stencil fixes

For mem->gmem we don't sample depth/stencil as it's native type.  So we
need to setup the swizzle state for the sampler based on the format used
for sampling.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: alpha-test

Needed by some games, like etuxracer and supertuxkart which use alpha
test rather than blending, to handle texture transparency.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx/compiler: implement SUB

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: use INDIRECT state load for shaders

With a debug option to force DIRECT (mainly to make it easier for
capturing cmdstream dumps).  Using INDIRECT for large shaders at least
makes a noticable reduction in CPU load, which helps for CPU limited
games.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: avoid stalling at ringbuffer wraparound

Because of how the tiling works, we can't really flush at arbitrary
points very easily.  So wraparound is handled by resetting to top of
ringbuffer.  Previously this would stall until current rendering is
complete.  Instead cycle through multiple ringbuffers to avoid a stall.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: emit markers to scratch registers

Emit markers by writing to scratch registers in order to "triangulate"
gpu lockup position from post-mortem register dump.  By comparing
register values in post-mortem dump to command-stream, it is possible to
narrow down which DRAW_INDX caused the lockup.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: split out WFI helper

Mostly just to give an easy debug/instrumentation point.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: fd_draw helper

Have a single helper that all draws come through.. mainly for a
convenient debug and instrumentation point.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx: fix gpu lockup in some piglit tests

The varying-out config comes from the inputs of the frag shader (so that
we aren't exporting unneeded varyinges).  The varyings-count should come
from the frag shader as well, to avoid a discrepency in configuration
and resulting gpu lockup.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno/a3xx/compiler: add LIT

Needed by glxgears and etuxracer ;-)

Signed-off-by: Rob Clark <robclark@freedesktop.org>

freedreno: multi-slice resources (cubemap, mipmap, etc)

Signed-off-by: Rob Clark <robclark@freedesktop.org>

glsl/builtins: Fix {texture1D,texture2D,shadow1D}ArrayLod availibility.

These functions are defined in EXT_texture_array, which makes no
mention of what shader types they should be allowed in.  At the time
EXT_texture_array was introduced, functions ending in "Lod" were
available only in vertex shaders, however this restriction was lifted
in later spec versions and extensions.

We already have the function lod_exists_in_stage() for figuring out
whether functions ending in "Lod" should be available, so just re-use
that.

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

i965: Use brw_stage_state for WM data as well.

This gets the VS, GS, and PS all using the same data structure.

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

i965: Increase the size of brw_stage_state::surf_offset.

Since BRW_MAX_WM_SURFACES is greater than BRW_MAX_VEC4_SURFACES, the
existing array isn't large enough to be used by the WM.  Increasing it
will make it possible to share them.

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

i965: Add comments to the new brw_state_state structure's fields.

These are largely based on the similar fields in brw->wm.

v2: Add a better comment than "Scratch buffer".

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

mesa: Rename MESA_shader_integer_mix to EXT_shader_integer_mix

Everyone at the Khronos meeting was as surprised that GLSL didn't
already support this as we were.  Several vendors said they'd ship it,
but there didn't seem to be enough interest to put in the effort to make
it ARB or KHR.

v2: Fix a couple typos and rename the spec file to
EXT_shader_integer_mix.spec.  Suggested by Roland.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

radeonsi: fix and enable transform feedback for CIK

The CP_STRMOUT_CNTL register was moved again.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

radeonsi: fix gl_InstanceID with non-zero start_instance

start_instance doesn't affect gl_InstanceID.

There's no piglit test, but it's kinda obvious the code was wrong.

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

gallium: comment that INSTANCEID doesn't include start_instance

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

radeonsi: enable streamout AKA transform feedback for SI

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: implement streamout shader support

The shader is responsible for writing to streamout buffers using
the TBUFFER_STORE_FORMAT_* instructions.

The locations of some input SGPRs and VGPRs are assigned dynamically, because
the input SGPRs controlling streamout are not declared if they are not needed,
decreasing the indices of all following inputs.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>