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>
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>
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>
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
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
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>
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>
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: 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: 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/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/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: 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: 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: 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: 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: 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: 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: 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>
st/omx/dec/h264: fix prevFrameNumOffset handling

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