haiku: Clean up code, use target-helpers

* Thanks for the help xexaxo!

haiku: Drop haiku-softpipe.c; fix extern C

* It isn't needed any longer as we're
  moving in the code that called it.
* The winsys code is C, so make sure
  we include the header in the extern C

haiku: Correct Haiku softpipe library

* Use LoadableModule vs SharedLibrary

haiku: Add first Haiku renderer (softpipe)

* This shared library gets parsed by the
  system as a system "add-on"

haiku: Build Haiku's libGL from within Mesa

* This in essence means that Mesa would be
  taking control of Haiku's OpenGL kit.
* This works by dispatching renderers from the
  OpenGL add-ons directory

glsl: Define isnormal for Oracle Solaris Studio.

This patch fixes this Oracle Solaris Studio build error.

"../../src/glsl/ir_constant_expression.cpp", line 1398: Error: The function "isnormal" must have a prototype.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>

r600g: texture offsets for non-TXF instructions

All texture instructions can use offsets, not just TXF. Offsets into
the literals array were wrong, too.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>

r600g: remove an assertion causing a crash at context cleanup

Compute samplers are advertised, but not implemented.
I think that's intentional.

r300g: remove unused function r300_lacks_vertex_textures

mesa: Don't return any data for GL_SHADER_BINARY_FORMATS

We return 0 for GL_NUM_SHADER_BINARY_FORMATS, so
GL_SHADER_BINARY_FORMATS should not write any data to the application
buffer.

Fixes piglit test 'arb_get_program_binary-overrun shader'.

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

svga: fix incorrect memcpy src in svga_buffer_upload_piecewise()

As we march over the source buffer we're uploading in pieces, we
need to memcpy from the current offset, not the start of the buffer.
Fixes graphical corruption when drawing very large vertex buffers.

Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matthew McClure <mcclurem@vmware.com>

util: when packing depth values, round to nearest.

This patch adds the lrint, lrintf, llrint, and llrintf rounding utility
functions. When packing unorm depth values, we will round to nearest.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

radeonsi/compute: Fix segfault caused by recent refactoring

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

radeonsi: Fix build

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
https://bugs.freedesktop.org/show_bug.cgi?id=70106

configure: set HAVE_COMMON_DRI when building only swrast

With commit cb1febb07, I have incorrectly removed HAVE_COMMON_DRI
assuming that swrast does not need to build the translations for
driconf options, as effectively swrast/drisw does not use them.

With the incoming unification work of dri and drisw, it makes
sense just to revert the offending hunk.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70057
Reported-by: Vinson Lee <vlee@freedesktop.org>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

radeonsi/compute: fix bind_compute_sampler_states() breakage

Remove the assignment and the no-op function.

i965/fs: Improve accuracy of dFdy() to match dFdx().

Previously, we computed dFdy() using the following instruction:

  add(8) dst<1>F src<4,4,0)F -src.2<4,4,0>F { align1 1Q }

That had the disadvantage that it computed the same value for all 4
pixels of a 2x2 subspan, which meant that it was less accurate than
dFdx().  This patch changes it to the following instruction when
c->key.high_quality_derivatives is set:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }

This gives it comparable accuracy to dFdx().

Unfortunately, align16 instructions can't be compressed, so in SIMD16
shaders, instead of emitting this instruction:

  add(16) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1H }

We need to unroll to two instructions:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }
  add(8) (dst+1)<1>F (src+1)<4,4,1>.xyxyF -(src+1)<4,4,1>.zwzwF { align16 2Q }

Fixes piglit test spec/glsl-1.10/execution/fs-dfdy-accuracy.

Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>

gallium/tests: fix SHADER typo

gallium-egl: use standard variable types over EGLBoolean/EGLint

The inferface/prototype in native_wayland_bufmgr.h uses boolean/int, as
well as the rest of the file. Convert to improve consistency and to
prevent gcc compiler warnings due to type miss-match.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

gallium: remove old bind_*_sampler_states() functions

The new bind_sampler_states() function takes a shader argument to
specify the shader stage.

gallium/docs: update bind_sampler_states() documentation

cso: make sure all sampler states are set/cleared

freedreno: use new bind_sampler_states() function

svga: don't hook in old bind_fragment_sampler_states() functions

radeon: don't use old bind_vertex/fragment_sampler_states() hooks

i915g: remove old bind_vertex/fragment_sampler_states() hooks

noop: remove old bind_*_sampler_states() functions

galahad: remove old bind_*_sampler_states() functions

vl: remove old bind_fragment_sampler_states() calls

util: remove old bind_fragment_sampler_states() calls from blitter code

draw: remove use of old bind_fragment_sampler_states()

nouveau: remove old bind_*_sampler_states() functions

cso: remove use of old bind_*_sampler_states() functions

rbug: remove old bind_*_sampler_states() functions

identity: remove old bind_*_sampler_states() functions

trace: remove old bind_*_sampler_states() functions

ilo: don't hook up old bind_*_sampler_states() functions

llvmpipe: remove old bind_*_sampler_states() functions

softpipe: remove old bind_*_sampler_states() functions

clover: remove bind_compute_sampler_states() calls

gallium/tests: use pipe_context::bind_sampler_states()

gallium/tools: update dump_state.py to use bind_sampler_states()

nouveau: implement pipe_context::bind_sampler_states()

softpipe: implement pipe_context::bind_sampler_states()

radeon: implement pipe_context::bind_sampler_states()

svga: implement pipe_context::bind_sampler_states()

trace: implement pipe_context::bind_sampler_states()

rbug: implement pipe_context::bind_sampler_states()

noop: implement pipe_context::bind_sampler_states()

llvmpipe: implement pipe_context::bind_sampler_states()

ilo: implement pipe_context::bind_sampler_states()

identity: implement pipe_context::bind_sampler_states()

i915g: implement pipe_context::bind_sampler_states()

galahad: implement pipe_context::bind_sampler_states()

clover: use pipe_context::bind_sampler_states() if non-null

vl: use pipe_context::bind_sampler_states() if non-null

util: use pipe_context::bind_sampler_states() if non-null

draw: use pipe_context::bind_sampler_states() if non-null

cso: use pipe_context::bind_sampler_states() if non-null

gallium: add pipe_context::bind_sampler_states()

The bind_vertex/geometry/fragment/compute_sampler_states() functions
will be replaced by a single functions.

r300g: rename r300_bind_sampler_states to r300_bind_fragment_sampler_states

draw: rename bind_sampler_states variables

Put 'fragment' in the names.  In preparation for upcoming function
renaming.

r600g: fix ínitialization of non_disp_tiling flag

This fixes a regression caused by e64633e8c3a5498998a45ab721bf80edca101cf5

r600g,radeonsi: create aux_context last

This fixes a regression caused by 68f6dec32ed5eede361f76c8dbdf897652659baf.

r300g/swtcl: don't call draw_prepare_shader_outputs

st/mesa: silence warning about unhandled enum in switch statement

mesa: fix make check for ARB_texture_gather

Clean up inconsistency in enum decoration:
- Use the undecorated enums where possible.
- MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB remains decorated, since it
  has no undecorated equivalent in GL4.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70054
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

docs: Mark off ARB_texture_gather

i965/hsw: Apply gather4 RG32F w/a using SCS instead of shader.

The new surface channel select bits allow us to avoid having to
recompile the shader for this workaround.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Enable ARB_texture_gather on Gen7

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: use gather slots in the binding table for gather4.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Emit a second set of SURFACE_STATE for gather4 from textures.

This allows us to use a different surface format for gather4, which is
required for R32G32_FLOAT to work on Gen7.

V4: - Only emit alternate surface state for shaders which will actually
      use it.
    - Pass a simple 'for_gather' flag rather than a function pointer.
      The callee can decide what w/a to apply.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: make room in the binding table for a full alternate set of surface_states

Worst-case is that *every* texunit uses a format that needs overriding.

V4: Place the gather slots last, so shaders which don't use gather don't
    get penalized by having a huge binding table.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Add BRW_SURFACEFORMAT_R32G32_FLOAT_LD, required for IVB gather4 w/a

gather4 GREEN channel against a surface with format R32G32_FLOAT doesn't work
correctly on IVB. w/a from bspec:

   - use R32G32_FLOAT_LD = 0x97 instead, for gather4 only.
   - select BLUE channel to read GREEN

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: w/a for gather4 green RG32F

V4: Only flag quirks if there are any uses of gather in the shader,
    to avoid spurious recompiles just because someone happened to use
    RG32F.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

glsl: flag shaders which use gather4 at all

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/vs: Add support for ir_tg4

Pretty much the same as the FS case. Channel select goes in the header,

V2: Less mangling.
V3: Avoid sampling at all, for degenerate swizzles.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Add support for ir_tg4

Lowers ir_tg4 (from textureGather and textureGatherOffset builtins) to
SHADER_OPCODE_TG4.

The usual post-sampling swizzle workaround can't work for ir_tg4,
so avoid doing that:

* For R/G/B/A swizzles use the hardware channel select (lives in the
   same dword in the header as the texel offset), and then don't do
   anything afterward in the shader.
* For 0/1 swizzles blast the appropriate constant over all the output
   channels instead of sampling.

V2: Avoid duplicating header enabling block
V3: Avoid sampling at all, for degenerate swizzles.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: add SHADER_OPCODE_TG4

Adds the Gen7 message IDs, a new SHADER_OPCODE_TG4 pseudo-op, and
low-level support for emitting it via generate_tex().

V3: Updated for changes in master.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

glsl: add texture gather changes

V2 [Chris Forbes]:
   - Add new pattern, fixup parameter reading.

V3: Rebase onto new builtins machinery

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: add texture gather changes

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: fix bogus swizzle in brw_cubemap_normalize

When used with a cube array in VS, failed assertion in ir_validate:

   Assignment count of LHS write mask channels enabled not
   matching RHS vector size (3 LHS, 4 RHS).

To fix this, swizzle the RHS correctly for the writemask.

This showed up in the ARB_texture_gather tests, which exercise cube
arrays in the VS.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

r600/llvm: Adds support for MSAA

r600g/llvm: Undef z and w component of 2D TXP inst

r600g/llvm: fix txq for texture buffer

i965: compute DDX in a subspan based only on top row

Consider only the top-left and top-right pixels to approximate DDX in a 2x2
subspan, unless the application requests a more accurate approximation via
GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the
new driconf option disable_derivative_optimization.

This results in a less accurate approximation.  However, it improves the
performance of Xonotic with Ultra settings by 24.3879% +/- 0.832202% (at 95.0%
confidence) on Haswell.  No noticeable image quality difference observed.

The improvement comes from faster sample_d.  It seems, on Haswell, some
optimizations are introduced to allow faster sample_d when all pixels in a
subspan have the same derivative.  I considered SAMPLE_STATE too, which allows
one to control the quality of sample_d on Haswell.  But it gave much worse
image quality without giving better performance comparing to this change.

No piglit quick.tests regression on Haswell (tested with v1).

v2: better guess for precompile program key

Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

i965/blorp: Use passed in framebuffer rather than ctx->DrawBuffer

We have the destination framebuffer object passed in; there's no need to
go digging around in the context.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

ralloc: Remove the rzalloc-based new/delete operator definition macro.

Using it encourages the (IMHO worrying) practice of leaving member
variables uninitialized in constructor definitions.  This macro
shouldn't be necessary anymore after the last patch series fixing all
its users to initialize all member variables from the class
constructor.  Remove it.

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

st/mesa: Switch glsl_to_tgsi_instruction to the non-zeroing allocator.

All member variables of glsl_to_tgsi_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

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

mesa/program: Switch ir_to_mesa_instruction to the non-zeroing allocator.

All member variables of ir_to_mesa_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

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

i965: Switch vec4_live_variables to the non-zeroing allocator.

All member variables of vec4_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

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

i965: Switch fs_live_variables to the non-zeroing allocator.

All member variables of fs_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

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

i965: Switch fs_inst to the non-zeroing allocator.

All member variables of fs_inst are already being initialized from its
constructor, it's not necessary to use rzalloc to allocate its memory,
and doing so makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

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

i965: Switch ip_record to the non-zeroing allocator.

All member variables of ip_record are already being initialized from
its constructor, it's not necessary to use rzalloc to allocate its
memory, and doing so makes it more likely that we will start relying
on the allocator to zero out all memory if the class is ever extended
with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

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

i965: Initialize all member variables of cfg_t on construction.

The cfg_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.  Initialize all fields from the
constructor and stop using the zeroing allocator.

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

i965: Initialize all member variables of bblock_t on construction.

The bblock_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.  Initialize all fields from the
constructor and stop using the zeroing allocator.

v2: Use zero initialization for numeric types instead of default construction.

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

glsl: Switch ast_type_qualifier to the non-zeroing allocator.

All member variables of ast_type_qualifier are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

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

glsl: Switch ast_node to the non-zeroing allocator.

All member variables of ast_node are already being initialized from
its constructor, but some of its derived classes were leaving members
uninitialized -- Fix them.

Using rzalloc makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables.  That's bad because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind.

v2: Use NULL initialization instead of default construction for pointers.

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

i965: Initialize all member variables of vec4_instruction on construction.

The vec4_instruction object relies on the memory allocator zeroing out
its contents before it's initialized, which is quite an unusual
practice in the C++ world because it ties objects to some specific
allocation scheme, and gives unpredictable results when an object is
created with a different allocator -- Stack allocation, array
allocation, or aggregation inside a different object are some of the
useful possibilities that come to my mind.  Initialize all fields from
the constructor and stop using the zeroing allocator.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

The _mesa_glsl_parse_state object relies on the memory allocator
zeroing out its contents before it's initialized, which is quite an
unusual practice in the C++ world because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind.  Initialize all fields
from the constructor and stop using the zeroing allocator.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>