mesa/sso: Implement _mesa_DeleteProgramPipelines

Implement DeleteProgramPipelines based on the VAO code.

This was originally included in another patch, but it was split out by
Ian Romanick.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa/sso: Add pipeline container/state

V1:
* Extend gl_shader_state as pipeline object state
* Add a new container gl_pipeline_shader_state that contains
   binding point of the previous object
* Update mesa init/free shader state due to the extension of
   the attibute
* Add an init/free pipeline function for the context

V2:
* Rename gl_shader_state to gl_pipeline_object
* Rename Pipeline.PipelineObj to Pipeline.Current
* Formatting improvement

V3 (idr):
* Split out from previous uber patch.
* Remove '#if 0' debug printfs.

V4 (idr):
* Fix some errors in comments.  Suggested by Jordan.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa: Add a mutex and refcounting to gl_shader_state

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa: Make get_shader_flags publicly available

Future patches will use this function outside shaderapi.c.

This was originally included in another patch, but it was split out by
Ian Romanick.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa/sso: Add extension entry points for GL_ARB_separate_shader_objects

Nothings implemented yet but glProgramUniform* which are mostly a
copy/paste of the older function glUniform*

I create dedicated pipelineobj.[ch] file that will contains function
related to the "new" pipeline container object.

V2: formatting improvement

V3:
* indentation fix
* Update copyright
* Add a comment on ProgramParameteri already present in another extension
* Remove TODO, will be readded on correct patch

V4 (idr):
* Fix dispatch_sanity unit test
* Make extension string available in core profiles (instead of just
  compatibility).
* Trivial reformating

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl/sso: Add parser and AST-to-HIR support for separate shader object layouts

GL_ARB_separate_shader_objects adds the ability to specify location
layouts for interstage inputs and outputs.

In addition, this extension makes 'in' and 'out' generally available for
shader inputs and outputs.  This mimics the behavior of
GL_ARB_explicit_attrib_location.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa/sso: Add extension tracking for ARB_separate_shader_objects

This adds the necessary bits for both the API and the GLSL compiler.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa: Refactor per-stage link check to its own function

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

specs: MESA_query_renderer.spec resolve a couple of typos

Cc: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

configure: use shared-glapi when more than one gl* API is used

Current behaviour states that shared-glapi is usefull when building
with dri, which is not the case. Shared-glapi is used to dispatch
the gl* functions across the one or more gl api's which can be dri
based but do not need to be.

Fixed the following build

 ./configure --enable-gles2 --disable-dri --enable-gallium-egl \
      --with-egl-platforms=fbdev --with-gallium-drivers=swrast

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75098
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

configure: use default dri drivers whenever opengl and dri are enabled

Commit ee55500c22a(configure: cleanup classic dri drivers handling)
cleaned up the logic handling autodetection of dri drivers, but missed
the case when one can explicitly disable dri, and still request opengl.

Fixes build issues for the following
./autogen.sh --disable-dri --with-gallium-drivers=swrast

While we're here, explicitly clear with_dri_drivers whenever building
without such drivers to prevent choking later on.

v2: Simplify with_dri_drivers handling.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75126
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Stop throwing away our double precision for time calculations.

Fixes negative times being reported in our perf debug.

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

meta: Add support for integer blits.

Compared to i965, the code generated doesn't use the AVG instruction.  But
I'm not sure that multisampled integer resolves are really that important
to worry about.

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

meta: Add support for doing MSAA to MSAA blits.

These are non-stretched, non-resolving blits, so it's just a matter of
sampling once from our gl_SampleID and storing that to our color/depth.

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

meta: Save and restore a bunch of MSAA state.

We're disabling GL_MULTISAMPLE, so we didn't need to worry about a lot of
that state.  But to do MSAA to MSAA blits, we need to start handling more
state.

v2: Fix pasteo caught by Kenneth.

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

meta: Try to do blending of sRGB values in linear colorspace.

Blending of values would occur when doing GL_LINEAR filtering with
scaling, and in an upcoming commit when doing MSAA resolves.

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

meta: Add support for doing multisample resolves.

Note that this doesn't handle GL_EXT_multisample_scaled_blit yet.  The
i965 code for that extension bakes in knowledge of the sample positions
(well, knowledge of the sample positions aligned to a lower-resolution
grid), which we would have to do at runtime somehow for meta.

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

i965: Fix miptree matching for multisampled, non-interleaved miptrees.

We haven't been executing this code before the meta-blit case, because
we've been flagging the miptree as validated at texstorage time, and never
having to revalidate.

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

mesa: Remove unnecessary condition.

Identified by Valgrind memory check. Initialized block-opaque in a
different patch. This test seems unnecessary. If opaque must be true,
just set to true.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>

clover: Unabbreviate a few data accessor names for consistency.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Replace the transfer(new ...) idiom with a safer create(...) helper function.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Migrate a bunch of pointers and references in the object tree to smart references.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Allow storing a range into a container of different (but compatible) element type.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Define an intrusive smart reference class.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Some improvements for the intrusive pointer class.

Define some additional convenience operators, clean up the
implementation slightly, and rename it to 'intrusive_ptr' for reasons
that will be obvious in the next commit.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

clover: Fix up NULL constant pointer arguments.

Tested-by: Tom Stellard <thomas.stellard@amd.com>

tgsi_ureg: add property_gs_invocations

Fixes a build break in state_tracker/st_program.c

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75278
Reviewed-by: Dave Airlie <airlied@redhat.com>

i965: Enable Broadwell support.

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

i965/fs: Implement FS_OPCODE_[UN]PACK_HALF_2x16_SPLIT[_XY] opcodes.

I'd neglected to port these to Broadwell.  Most of this code is copy
and pasted from Gen7, but instead of using F32TO16/F16TO32, we just
use MOV with HF register types.

Fixes fs-packHalf2x16 and fs-unpackHalf2x16 tests (both the ARB
extension and ES 3.0 variants).

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

i965: Drop bogus F32TO16/F16TO32 instructions on Broadwell - use MOV.

Broadwell removed the F32TO16 and F16TO32 instructions.  However, it has
actual support for HF values, so they're actually just MOV.

Fixes vs-packHalf2x16 and vs-unpackHalf2x16 tests (both the ARB
extension and ES 3.0 variants).

v2: Emulate F32TO16's align16 zeroing bug, since Chad's front end code
    relies on it happening.  We can probably refactor this code to be
    better later.

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

i965: Create a hardware context before initializing state module.

brw_init_state() calls brw_upload_initial_gpu_state().  If hardware
contexts are enabled (brw->hw_ctx != NULL), this will upload some
initial invariant state for the GPU.  Without hardware contexts, we
rely on this state being uploaded via atoms that subscribe to the
BRW_NEW_CONTEXT bit.

Commit 46d3c2bf4ddd227193b98861f1e632498fe547d8 accidentally moved
the call to brw_init_state() before creating a hardware context.
This meant brw_upload_initial_gpu_state would always early return.
Except on Gen6+, we stopped uploading the initial GPU state via
state atoms, so it never happened.

Fixes a regression since 46d3c2bf4ddd227193b98861f1e632498fe547d8.

Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Implement scratch read/write support for Broadwell.

To make sure that both the Gen4 and Gen7 style messages work, I
initially disabled the SHADER_OPCODE_GEN7_SCRATCH_READ optimization,
ran Piglit, re-enabled it, and ran Piglit again.  Both worked fine.

Fixes 40 Piglit tests (most of the varying-packing category).

v2: Move num_regs assertion from gen8_fs_generator to
    gen8_set_dp_scratch_message() (suggested by Eric).

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

i965: Add Gen8 assembly support for DP Scratch messages.

The new accessors will make it easy to do Gen7-style scratch messages.

v2: Move num_regs assertion from gen8_fs_generator into
    gen8_set_dp_scratch_message() (suggested by Eric).

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

i965: Store absolute thread count in max_wm_threads on Broadwell.

In the past, 3DSTATE_PS took an absolute number of threads.  Conversely,
on Broadwell you always program 64, and it implicitly scales based on
the GT-level with no special programming.  So, I stored 64 in
brw_device_info::max_wm_threads.

However, I didn't realize that we also use max_wm_threads to compute the
size of the scratch space buffer.  In that case, we really need the
absolute number of threads.

This patch hardcodes 3DSTATE_PS to use the value it expects, and changes
max_wm_threads back to a (completely fake) absolute thread count (once
again copied from Haswell).

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

i965: Use MOV, not OR for setting URB write channel enables on Gen8+.

On Broadwell, g0.5 contains the "Scratch Space Pointer"; using OR
puts some bits of that into "ignored" sections of our message header.

While this doesn't hurt, it's also not terribly /useful/.  Using MOV
is sufficient to set the only interesting bits in this part of the
message header.

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

i965: Implement a CS stall workaround on Broadwell.

According to the latest documentation, any PIPE_CONTROL with the
"Command Streamer Stall" bit set must also have another bit set,
with five different options:

   - Render Target Cache Flush
   - Depth Cache Flush
   - Stall at Pixel Scoreboard
   - Post-Sync Operation
   - Depth Stall

I chose "Stall at Pixel Scoreboard" since we've used it effectively
in the past, but the choice is fairly arbitrary.

Implementing this in the PIPE_CONTROL emit helpers ensures that the
workaround will always take effect when it ought to.

Apparently, this workaround may be necessary on older hardware as well;
for now I've only added it to Broadwell as it's absolutely necessary
there.  Subsequent patches could add it to older platforms, provided
someone tests it there.

v2: Only flag "Stall at Pixel Scoreboard" when none of the other bits
    are set (suggested by Ian Romanick).

v3: Prefix the function with "gen8" (requested by Eric).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v2)
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: support instanced GS on gen7

v3:
 * Properly prevent dual object mode execution when
   the invocation count > 1

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: support gl_InvocationID for gen7

v2:
 * Make gl_InvocationID a system value

v3:
 * Properly shift from R0.1 into DST.4 by adding
   GS_OPCODE_GET_INSTANCE_ID

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: add gl_InvocationID variable for ARB_gpu_shader5

v2:
 * Make gl_InvocationID a system value

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

main/shaderapi: GL_GEOMETRY_SHADER_INVOCATIONS GetProgramiv support

v3:
 * Add check for ARB_gpu_shader5

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: initialize gl_geometry_program Invocations field

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl/linker: produce gl_shader_program Geom.Invocations

Grab the parsed invocation count, check for consistency
during linking, and finally save the result in
gl_shader_program Geom.Invocations.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: parse invocations layout qualifier for ARB_gpu_shader5

_mesa_glsl_parse_state in_qualifier->invocations will store the
invocations count.

v3:
 * Use in_qualifier to allow the primitive to be specied
   separately from the invocations count (merge_qualifiers)

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: Generate error for invalid input layout declarations

Fixes various piglit tests:
spec/glsl-1.50/compiler/incorrect-in-layout-qualifier-*.geom

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: convert GS input primitive to use ast_type_qualifier

We introduce a new merge_in_qualifier ast_type_qualifier
which allows specialized handling of merging input layout
qualifiers.

By merging layout qualifiers into state->in_qualifier, we
allow multiple input qualifiers. For example, the primitive
type can be specified specified separately from the
invocations count (ARB_gpu_shader5).

state->gs_input_prim_type is moved into state->in_qualifier->prim_type

state->gs_input_prim_type_specified is still processed separately
so we can determine when the input primitive is specified. This
is important since certain scenerios are not supported until after
the primitive type has been specified in the shader code.

v4:
 * Merge with compute shader input layout qualifiers

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Fix extra return value after winsys rb update refactor.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75172
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/vs: Use samplers for UBOs in the VS like we do for non-UBO pulls.

Improves performance of a dolphin emulator trace I had laying around by
3.60131% +/- 0.995887% (n=128).

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

i965/fs: Add an optimization pass to remove redundant flags movs.

We generate steaming piles of these for the centroid workaround, and this
quickly cleans them up.

total instructions in shared programs: 1591228 -> 1590047 (-0.07%)
instructions in affected programs:     26111 -> 24930 (-4.52%)
GAINED:                                0
LOST:                                  0

(Improved apps are l4d2, csgo, and dolphin)

Reviewed-by: Matt Turner <mattst88@gmail.com>

gallivm: add smallfloat to float conversion not relying on cpu denorm handling

The previous code relied on cpu denorm support for converting small float
formats (such r11g11b10_float and r16_float) to floats, otherwise denorms
are flushed to zero. We worked around that in llvmpipe blend code by
reenabling denorms, but this did nothing for texture sampling. Now it would
be possible to reenable it there too but I'm not really a fan of messing
with fpu flags (and it seems we can't actually do it reliably with llvm in
any case looking at some bug reports). (Not to mention if you actually have
a lot of denorms in there, you can expect some order-of-magnitude slowdown
with x86 cpus.)
So instead use code which adjusts exponents etc. directly hence not relying
on cpu denorm support for the rescaling mul.
(We still need the fpu flag handling as we can't do float-to-smallfloat
without using cpu denorms at least for now - I actually wanted to keep
both the old and new code and using one or the other depending on from where
it's called but that didn't work out as the parameter would have to be passed
through too many layers than I'd like.)

Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Si Chen <sichen@vmware.com>

st/omx/enc: add multi scaling buffers for performance improvement

Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

st/omx/dec/h264: fix prevFrameNumOffset handling

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

i965: Actually claim to support MSAA on Broadwell.

We need to advertise 8x, 4x, and 2x multisamples.  Previously, we only
claimed to support 0/1 samples.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Update physical width/height munging for 2x IMS MSAA.

I can't find any documentation to explain what ought to be done here, so
I simply guessed based on the pattern I observed in the 4x/8x cases.
It appears to work, but it could be totally wrong.

I was able to find the Sandybridge PRM quote from the comments in the
latest documentation: Shared Functions > 3D Sampler > Multisampled
Surface Behavior.  However, it only mentions 4x MSAA - not even 8x.

After a substantial amount more digging, I was able to find a second
page (incorrectly tagged) which confirmed the formulas in our code for
8x MSAA.  However, that page didn't mention 2x MSAA at all.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Enable smooth points when multisampling without point sprites.

According to the "Point Multisample Rasterization" of the OpenGL
specification (3.0 or later), smooth points are supposed to be enabled
implicitly when multisampling, regardless of the GL_POINT_SMOOTH flag.

However, if GL_POINT_SPRITE is enabled, you get square points no matter
what.  Core contexts always enable point sprites, so this effectively
makes smooth points go away, even in the case of multisampling.

Fixes Piglit's EXT_framebuffer_multisample/point-smooth tests.
(Yes, that's right folks, we actually have Piglit tests for this.)

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Thwack multisample enable bit in 3DSTATE_RASTER.

The meaning and effects of this bit are surprisingly complicated.

See Rasterization > Windower > Multisampling > Multisample ModesState.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Only use the SIMD16 program for per-sample shading on Broadwell.

This restriction carries forward from earlier platforms.  The code is
ported straight from gen7_wm_state.c.

v2: Actually do it right.
v3: Add missing _NEW_MULTISAMPLE bit (caught by Eric).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Set "Position XY Offset Select" bits in 3DSTATE_PS on Broadwell.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Add missing sample shading bits to Gen8's 3DSTATE_PS_EXTRA.

v2: Also set the "oMask Present to Render Target" bit, which is required
    for shaders that write oMask.  Otherwise the hardware won't expect
    the extra data.

v3: Add missing _NEW_MULTISAMPLE (caught by Eric).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/fs: Implement FS_OPCODE_SET_OMASK on Broadwell.

I made a few changes which I think simplify the code a bit compared to
the Gen7 implementation, but which are largely pointless.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/fs: Implement FS_OPCODE_SET_SAMPLE_ID on Broadwell.

Largely cut and paste from Gen7; it works the same way.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Disable MCS on Broadwell for now.

v2: Add a perf_debug() message to remind us to come back to this.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Use gen7_surface_msaa_bits in Broadwell SURFACE_STATE code.

We already set the number of samples, but were missing the MSAA layout
mode.  Reusing gen7_surface_msaa_bits makes it easy to set both.

This also lets us drop the Gen8 surface_num_multisamples function.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Use ffs() for sample counting in gen7_surface_msaa_bits().

The enumerations are just log2(num_samples) shifted by 3, which we can
easily compute via ffs().

This also makes it reusable for Broadwell, which has 2x MSAA.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Simplify Broadwell's 3DSTATE_MULTISAMPLE sample count handling.

These enumerations are simply log2 of the number of multisamples shifted
by a bit, so we can calculate them using ffs() in a lot less code.

Suggested by Eric Anholt.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

glsl: Silence "type qualifiers ignored on function return type" warning

The const in

   const unsigned foo(void);

is meaningless.  Removing it silences this warning:

src/glsl/ast_to_hir.cpp:1802:56: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]

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

glsl: Only warn for macro names containing __

From page 14 (page 20 of the PDF) of the GLSL 1.10 spec:

    "In addition, all identifiers containing two consecutive underscores
     (__) are reserved as possible future keywords."

The intention is that names containing __ are reserved for internal use
by the implementation, and names prefixed with GL_ are reserved for use
by Khronos.  Names simply containing __ are dangerous to use, but should
be allowed.

Per the Khronos bug mentioned below, a future version of the GLSL
specification will clarify this.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de>
Cc: Tapani Pälli <lemody@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Bugzilla: Khronos #11702

glcpp: Only warn for macro names containing __

Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the
GLSL ES spec (all versions) say:

    "All macro names containing two consecutive underscores ( __ ) are
    reserved for future use as predefined macro names. All macro names
    prefixed with "GL_" ("GL" followed by a single underscore) are also
    reserved."

The intention is that names containing __ are reserved for internal use
by the implementation, and names prefixed with GL_ are reserved for use
by Khronos.  Since every extension adds a name prefixed with GL_ (i.e.,
the name of the extension), that should be an error.  Names simply
containing __ are dangerous to use, but should be allowed.  In similar
cases, the C++ preprocessor specification says, "no diagnostic is
required."

Per the Khronos bug mentioned below, a future version of the GLSL
specification will clarify this.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de>
Cc: Tapani Pälli <lemody@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Bugzilla: Khronos #11702

configure: Use LLVM shared libraries by default

Linking with LLVM static libraries is easily broken by changes to
the llvm-config program or when LLVM adds, removes, or changes library
components.  Keeping up with these changes requires a lot of maintanence
effort to keep the build working on the master and stable branches.

Also, because of issues in the past LLVM static libraries, the release
manager is currently configuring with --with-llvm-shared-libs when
checking the build before release.  Enabling shared libraries by
default would allow the release manager to run ./configure with
no arguments, and be reasonably confident that the build would succeed.

Acked-by: Emil Velikov <emil.l.velikov@gmail.com>

i965/fs: Allocate the param_size array dynamically.

Useful because the total number of uniform components might exceed
MAX_UNIFORMS * 4 in some cases because of the image metadata we'll be
passing as push constants.

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

i965/fs: Use a separate variable to keep track of the last uniform index seen.

Like the VEC4 back-end does.  It will make dynamic allocation of the
param_size array easier in a future commit.

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

freedreno: tweak ringbuffer sizes/count

Since we are now consuming two ringbuffers at a time, we probably want a
pool larger than 4.. but we don't need each individual ringbuffer to be
so large, so offset the pool size increase by reducing rb size.

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

freedreno/a3xx/compiler: scheduling/legalize fixes

It seems the write-after-read hazard that applies to texture fetch
instructions, also applies to sfu instructions.

Also, cat5/cat6 instructions do not have a (ss) bit, so in these
cases we need to insert a dummy nop instruction with (ss) bit set.

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

i965: Have brw_imm_vf4() take the vector components as integer values.

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

i965: Add helper function to find out the signedness of a register type.

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

i965/vec4: Use swizzle() in the ARB_vertex_program code.

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

i965/fs: Use offset() in the ARB_fragment_program code.

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

i965/fs: Remove fs_reg::retype.

There doesn't seem to be any reason for it to be a method, and it's
surprising that the expression 'reg.retype(t)' doesn't retype its
object but rather it creates a temporary with the new type.  Use
'retype(reg, t)' instead.

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

i965/vec4: Trivial improvements to the with_writemask() function.

Add assertion that the register is not in the HW_REG or IMM file,
calculate the conjunction of the old and new mask instead of replacing
the old [consistent with the behavior of brw_writemask(), causes no
functional changes right now], make it static inline to let the
compiler do a slightly better job at optimizing things, and shorten
its name.

v2: Assert that the new writemask is not zero to avoid undefined
    hardware behaviour.

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

i965: Make sure that backend_reg::type and brw_reg::type are consistent for fixed regs.

And define non-mutating helper functions to retype fixed and normal
regs with a common interface.  At some point we may want to get rid of
::fixed_hw_reg completely and have fixed regs use the normal register
data members (e.g. backend_reg::reg to select a fixed GRF number,
src_reg::swizzle to store the swizzle, etc.), I have the feeling that
this is not the last headache we're going to get because of the
multiple ways to represent the same thing and the different register
interface depending on the file a register is stored in...

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

i965/vec4: Add non-mutating helper functions to modify src_reg::swizzle and ::negate.

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

i965: Add non-mutating helper functions to modify the register offset.

Yes, we could avoid having four copies of essentially the same code by
using templates here.

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

i965/vec4: Fix off-by-one register class overallocation.

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

i965: Unify fs_generator:: and vec4_generator::mark_surface_used as a free function.

This way it can be used anywhere.  I need it from the visitor.

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

i965: Move up duplicated fields from stage-specific prog_data to brw_stage_prog_data.

There doesn't seem to be any reason for nr_params, nr_pull_params,
param, and pull_param to be duplicated in the stage-specific
subclasses of brw_stage_prog_data.  Moving their definition to the
common base class will allow some code sharing in a future commit, the
removal of brw_vec4_prog_data_compare and brw_*_prog_data_free, and
the simplification of the stage-specific brw_*_prog_data_compare.

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

i965/vec4: Add constructor of src_reg from a fixed hardware reg.

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

i965: Enable fast depth clears.

They work fine now, too.

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

i965: Enable HiZ on Broadwell.

It appears to work fine.

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

i965: Implement HiZ resolves on Broadwell.

Broadwell's 3DSTATE_WM_HZ_OP packet makes this much easier.

Instead of programming the whole pipeline, we simply have to emit the
depth/stencil packets, a state override, and a pipe control.  Then
arrange for the state to be put back.  This is easily done from a single
function.

v2: Use minify(mt->logical_{width,height}0, level) in 3DSTATE_WM_HZ_OP
    instead of intel_mipmap_level's width/height fields.  Those were
    based on the physical width/height, and thus wrong for MSAA buffers.
    Eric also deleted those fields.

v3: Use 0xFFFF as the sample mask regardless of what the user set (as
    this operation is unrelated); set the drawing rectangle to the
    miplevel being operated on, rather than the whole surface; remove
    unnecessary MAX2(..., 1) around mt->logical_depth0 (all suggested
    by Eric Anholt).

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

i965: Refactor Gen8 depth packet emission.

The existing code followed the vtable function signature, which is not a
great fit: many of the parameters are unused, and the function still
inspects global state, making it less reusable.

This patch refactors the depth buffer packet emission code into a new
function which takes exactly the parameters it needs, and which uses no
global state.  It then makes the existing vtable function call the new
one.

Ideally, we would remove the vtable function, and clean up that
interface.  But that can happen once HiZ is working.

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

i965: Add #defines for the 3DSTATE_WM_HZ_OP packet's contents.

We're going to need these to implement HiZ.

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

i965: Bump generation check in code to disable HiZ at LODs > 0.

Broadwell's "HiZ Resolve" operation still has the restriction that the
rectangle primitive must be 8x4 aligned.  So I believe we still need
this.

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

i965: Program 3DSTATE_HIER_DEPTH_BUFFER properly on Broadwell.

HiZ buffers still don't exist, but when they do, we'll set them up.

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

i965: Pull format conversion logic out of brw_depthbuffer_format.

brw_depthbuffer_format is not very reusable at the moment, since it
uses global state (ctx->DrawBuffer) to access a particular depth buffer.

For HiZ on Broadwell, I need a function which simply converts the
formats.  However, at least one existing user of brw_depthbuffer_format
really wants the existing interface.  So, I've created a new function.

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

egl: clarify what _eglInitResource does

It is a helper called from the initializers of its subclasses.

Revert "egl: Unhide functionality in _eglInitContext()"

This reverts commit 1456ed85f0ed8b9c9f0abd6bd389a089fa3824b2.
_eglInitResource can and is supposed to be called on subclass objects.

Acked-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Revert "egl: Unhide functionality in _eglInitSurface()"

This reverts commit 498d10e230663f8604d00608cae6324f779c9cdd.
_eglInitResource can and is supposed to be called on subclass objects.

Acked-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

i965: Bump MaxTexMbytes from 1GB to 1.5GB.

Even with the other limits raised, TestProxyTexImage would still reject
textures > 1GB in size.  This is an artificial limit; nothing prevents
us from having a larger texture.  I stayed shy of 2GB to avoid the
larger-than-aperture situation.

For 3D textures, this raises the effective limit:
 - RGBA8:   645 -> 738
 - RGBA16:  512 -> 586
 - RGBA32F: 406 -> 465

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74130
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>

i965: Bump GL_MAX_CUBE_MAP_TEXTURE_SIZE to 8192.

Gen4+ supports 8192x8192 cube maps.  Ivybridge and later can actually
support 16384, but that would place GL_MAX_CUBE_MAP_TEXTURE_SIZE above
GL_MAX_TEXTURE_SIZE, which seems like a bad idea.

(Unfortunately, we can't bump GL_MAX_TEXTURE_SIZE to 16384 without
causing regressions due to awful W-tiled stencil buffer interactions.)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74130
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>

i965: Bump MAX_3D_TEXTURE_SIZE to 2048.

It's highly unlikely that there will be enough memory in the system to
allocate enough space for this, but we should still expose the hardware
limit.  It's what the Intel Windows driver does, and it seems most other
vendors do likewise.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74130
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>

docs: Trivial updates to MESA_query_renderer.spec

Fix the version and the status before sending to Khronos for listing in
the registry.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>