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>
(cherry picked from commit a4c734297f890eb7034793428ee20c28eaad5a69)
configure: cleanup libudev handling

Add the explicit note about the required version during configure.
Require the same version (151) of udev when building the pipe-loader.
Mention the udev version requirement in GBM Requires.private.

v2: Resolve a couple of silly typos. Spotted by Ilia
v3: Cleanup platfrom/platform typo. Spotten by Stefan

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 118c36adb4f2e3eec2327fccd59ed808f346aa73)
configure: don't require libudev for gbm or egl drm/wayland

After the loader changes libudev is no longer required for
gbm or the egl drm/wayland platforms.  Lets these build/run
on OpenBSD.

v2: preserve the libudev requirement for Linux as suggested
by Emil Velikov.

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 81799c82e47b34db6eeca34113016d2d8389669d)
linker: Split set_uniform_binding into separate functions for blocks and samplers

The two code paths are quite different, and there are some problems in
the handling of uniform blocks.  Future changes will cause these paths
to diverge further.  Ultimately, selecting between the two functions
will happen at the set_uniform_binding call site, and
set_uniform_binding will be deleted.

NOTE: This patch just moves code around.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 6e2f63b69e37c365094ce9bf7e2f9cd118cea01a)
linker: Various trivial clean-ups in set_sampler_binding

- Remove the spurious block left from the previous commit and re-indent.

- Constify elements.

- Make the spec reference in the code look like other spec references in
  the compiler.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 881c52f13f4a8ca1c80ca1766238d5100ddf283b)
linker: Fold set_uniform_binding into call site

In the next patch, we'll see that using
gl_shader_program::UniformStorage is not correct for uniform blocks.
That means we can't use ::UniformStorage to select between the sampler
path and the block path.  Instead we want to just use the type of the
variable.  That's never passed to set_uniform_binding, and it's easier
to just remove the function (especially for later patches in the series)
than to add another parameter.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 943b2d52bf5df6adde3c0abcb91d9a3899476ab0)
glsl: Allow explicit binding on atomics again

As of 943b2d52bf5, layout(binding) on an atomic would fail the assertion
here.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 92840aabf7a96583619a01a8257ef6f117f0ca50)

Conflicts:
	src/glsl/link_uniform_initializers.cpp
linker: Clean up "unused parameter" warnings

../../src/glsl/link_uniform_initializers.cpp:87:1: warning: unused parameter 'mem_ctx' [-Wunused-parameter]
../../src/glsl/link_uniform_initializers.cpp:87:1: warning: unused parameter 'type' [-Wunused-parameter]
../../src/glsl/link_uniform_initializers.cpp:127:1: warning: unused parameter 'mem_ctx' [-Wunused-parameter]
../../src/glsl/link_uniform_initializers.cpp:127:1: warning: unused parameter 'type' [-Wunused-parameter]

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 157391a41bc3e0222888d0450405867139ab4c9d)
linker: Set block bindings based on UniformBlocks rather than UniformStorage

For blocks, gl_shader_program::UniformStorage isn't very useful.  The
names stored there are the names of the elements of the block, so
finding blocks with an instance name is hard.  There is also only one
entry in ::UniformStorage for each element of a block array, and that is
a deal breaker.

Using ::UniformBlocks is what _mesa_GetUniformBlockIndex does.  I
contemplated sharing code between set_block_binding and
_mesa_GetUniformBlockIndex, but building the stand-alone compiler and
the unit tests make this hard.  I plan to return to this effort shortly.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit cc42717b50bd46c82ac7925c397cd105ac82d091)
linker: Set binding for all elements of UBO array

Previously, a UBO like

    layout(binding=2) uniform U {
        ...
    } my_constants[4];

wouldn't get any bindings set.  The code would try to set the binding of
U, but that would fail.  It should instead set the bindings for U[0],
U[1], ...

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 25a66568750c5826a077cbf549de92546c5fc6cf)
glsl: Propagate explicit binding information from the AST all the way to the linker

Information about the binding was not being properly communicated from
the front-end compiler to the linker.  As a result, the linker never
knew that any UBOs had explicit bindings!

Fixes the piglit test arb_shading_language_420pack-binding-layout.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: github@socker.lepus.uberspace.de [v0]
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 625cf8c874950a38e7afb404345611f0fad4d490)
glsl: Try vectorizing when seeing a repeated assignment to a channel.

When considering assignment expressions like:

    v.x += u.x;
    v.x += u.x;

the vectorizer would incorrectly keep going, attempting to find more
instructions to vectorize.  It would overwrite the saved assignment
to point at the second one, and increment channels a second time,
resulting in try_vectorize thinking the expression was a vec2 instead of
a float.

Instead, if we see a repeated assignment to a channel, just try to
vectorize everything we've found so far.  This clears the saved state
so it will start over.

Fixes Piglit's repeated-channel-assignments.vert.

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit ae2a03b5736037128fb071595717f300d5b3afd5)
i965: Avoid dependency hints on math opcodes

  Putting NoDDClr and NoDDChk dependency control on instruction
sequences that include math opcodes can cause corruption of channels.
Treat math opcodes like send opcodes and suppress dependency hinting.

Signed-off-by: Mike Stroyan <mike@LunarG.com>
Tested-by: Tony Bertapelli <anthony.p.bertapelli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit 602510395a96a1f6ca29189e4f5cfb3f07f21d23)
i965: Fix buffer overruns in MSAA MCS buffer clearing.

This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server.  Today we decided that the problem in compositors was equivalent
to a corruption bug we'd noticed recently in resizing MSAA-visual
glxgears, and debugging got a lot easier.

When we allocate our MCS MT, libdrm takes the size we request, aligns it
to Y tile size (blowing it up from 300x300=900000 bytes to 384*320=122880
bytes, 30 pages), then puts it into a power-of-two-sized BO (131072 bytes,
32 pages).  Because it's Y tiled, we attach a 384-byte-stride fence to it.
When we memset by the BO size in Mesa, between bytes 122880 and 131072 the
data gets stored to the first 20 or so scanlines of each of the 3 tiled
pages in that row, even though only 2 of those pages were allocated by
libdrm.  In the glxgears case, the missing 3rd page happened to
consistently be the static VBO that got mapped right after the first MCS
allocation, so corruption only appeared once window resize made us throw
out the old MCS and then allocate the same BO to back the new MCS.

Instead, just memset the amount of data we actually asked libdrm to
allocate for, which will be smaller (more efficient) and not overrun.
Thanks go to Kenneth for doing most of the hard debugging to eliminate a
lot of the search space for the bug.

Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77207
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 7ae870211ddc40ef6ed209a322c3a721214bb737)
Update VERSION to 10.1.1

In preparation for the 10.1.1 release.
docs: Add release notes for 10.1.1
docs: Add the MD5 sums for the 10.1.1 release tar files.

Now that those files have been generated.
r600g: Disable LLVM by default at runtime for graphics

For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the iceberg.

So building Mesa with --enable-r600-llvm-compiler is currently not
recommended for anyone who doesn't want to work on fixing those issues.
However, for protection of users who end up enabling it anyway for some
reason, let's disable the LLVM backend at runtime by default. It can be
enabled with the environment variable R600_DEBUG=llvm.

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
(cherry picked from commit 7286739b9beea4683a29fe91850688a07ce23e1a)
mesa: Fix glGetVertexAttribi(GL_VERTEX_ATTRIB_ARRAY_SIZE)

mesa currently returns 4 when GL_VERTEX_ATTRIB_ARRAY_SIZE is queried
for a vertex array initially set up with size=GL_BGRA. This patch
makes changes to return size=GL_BGRA as required by the spec.

Fixes Khronos OpenGL CTS test: vertex_array_bgra_basic.test

V2: Use array->Format instead of adding a new variable

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit fdd8bebc22f167f19d9cafbe2e7c189cb3720bcb)
mesa: fix check for dummy renderbuffer in _mesa_FramebufferRenderbufferEXT()

According to the spec:
	<renderbuffertarget> must be RENDERBUFFER and <renderbuffer>
	should be set to the name of the renderbuffer object to be
	attached to the framebuffer.  <renderbuffer> must be either
	zero or the name of an existing renderbuffer object of type
	<renderbuffertarget>, otherwise an INVALID_OPERATION error is
	generated.

This patch changes the previous returned GL_INVALID_VALUE to
GL_INVALID_OPERATION.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76894

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
(cherry picked from commit 9927180714662456ff7b895221f67112f2567a53)