c11/threads: don't include assert.h if the assert macro is already defined

In the gallium code, the assert() macro could come from either the
system's assert.h file (via c11/threads.h) or from gallium's u_debug.h.
It looks like all known assert.h files unconditionally #undef assert
before defining their own version.  So the assert you get depends on
whether threads.h or u_debug.h was included last.

In the gallium code we really want to use the assert() from u_debug.h
(it behaves better on Windows).  In gallium, c11/threads.h is only
included after u_debug.h in the os_thread.h wrapper.  So Adding
an #ifndef assert test in the threads*.h files avoids using the system's
assert().

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
nouveau: use DLOPEN_LIBS instead of -ldl

libdl does not exist on many platforms which have dlopen in libc.

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
nouveau: don't assume libdrm include prefix

drm headers may be installed in a different directory

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
llvmpipe: Tighten check for alpha-only formats

The AoS version of ld_build_blend_factor was assuming that if the first
channel was alpha, there were no rgb components.

Fixes glean/blendFunc on System z.  No piglit regressions on x86_64.
The shortcut is still used in tests like spec/ARB_framebuffer_object/
fbo-alpha.

Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
radeon: Move r600_need_dma_space to common code

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
radeonsi: Implement DMA blit

This code is a slightly modified version of evergreen_dma_blit (and
evergreen_dma_copy as well as evergreen_dma_copy_tile).
It would be nice to share some of the code in the long term.

I have reused some "cik"-prefixed functions that also return the right
value for SI. I am not sure if they should be renamed.

v2: Marek> removed gfx.flush in si_dma_copy_tile

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
winsys/radeon: only add duplicate relocations for DMA if VM isn't supported

Also rewrite the comment for it to be readable and reorder the code.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: don't flush the gfx IB explicitly before doing DMA

It's flushed by calling r600_context_bo_reloc.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
r600g: deobfuscate async DMA code

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
r600g: use more appropriate names for async DMA functions

*_dma_copy calls either *_dma_copy_buffer or *_dma_copy_tile.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
mesa: fix texture border handling for cube arrays

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: allow generating mipmaps for cube arrays

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: fix software fallback for generating mipmaps for cube arrays

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: fix software fallback for generating mipmaps for 3D textures

It didn't use the driver-provided src/dstRowStride at all.
This was broken for the cases when stride != width*bpp.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: fix generating mipmaps for cube arrays

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
gallium/u_gen_mipmap: remove the software fallback

The last changes to it are from 2008 and 2009.
It doesn't support most texture formats and some texture targets.
Nobody can possibly be using this.

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: drop the lowering of quad strips to triangle strips

This fallback to triangle strips is silly and should be done in drivers
if they need it.

This should fix the case when quad strips are used with flatshading that is
enabled by the "flat" GLSL varying modifier. It also fixes primitive restart
for quad strips.

This fixes piglit:
  NV_primitive_restart/primitive-restart-draw-mode-quad_strip

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
nvc0/ir: move sample id to second source arg to fix sampler2DMS

The nvc0 texfetch instruction expects the sample id to be in the second
source (usually used for the offset) rather than as part of the texture
coordinate.

This fixes all the sampler2DMS/Array tests on nvc0.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
gallium: add b5g6r5 srgb format

GL generally doesn't seem to allow srgb formats with less (or more) than 8 bit
for the rgb channels, though some hw could easily do it (typically for formats
with up to 10 bits for the rgb channels, at least for formats with less than 8
bits support is likely widespread even). While it may be true there aren't
really any benefits for such formats, we need for it for d3d, though luckily
only for b5g6r5_srgb it seems.
So add this format along with the util code for conversion - since that util
code is heavily tuned for 8bit srgb this isn't really all that well optimized
and rounding doesn't seem right but at least it should give some halfway
meaningful results.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: add support for b5g6r5_srgb

The conversion code for srgb was tuned for n x 4x8bit AoS -> 4 x nxfloat SoA
(and vice versa), fix this to handle also 16bit 565-style srgb formats.
Still not really all that generic, things like r10g10b10a2_srgb or
r4g4b4a4_srgb wouldn't work (the latter trivial to fix, the former would not
require more work to not crash but near certainly need some higher precision
calculation) but not needed right now.
The code is not fully optimized for this (could use more direct calculation
instead of expanding to 8-bit range first) but should be good enough.

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