nv50,nvc0: use clip_halfz setting when creating rasterizer state

This enables the ARB_clip_control extension.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.4" <mesa-stable@lists.freedesktop.org>
configure.ac: roll up a program for the sse4.1 check

So when checking/building sse code we have three possibilities:
 1 Old compiler, throws an error when using -msse*
 2 New compiler, user disables sse* (-mno-sse*)
 3 New compiler, user doesn't disable sse

The original code, added code for #1 but not #2. Later on we patched
around the lack of handling #2 by wrapping the code in __SSE4_1__.
Yet it lead to a missing/undefined symbol in case of #1 or #2, which
might cause an issue for #2 when using the i965 driver.

A bit later we "fixed" the undefined symbol by using #1, rather than
updating it to handle #2. With this commit we set things straight :)

To top it all up, conventions state that in case of conflicting
(-enable-foo -disable-foo) options, the latter one takes precedence.
Thus we need to make sure to prepend -msse4.1 to CFLAGS in our test.

v2: Clean the #includes. Suggested by Ilia, Matt & Siavash.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Tested-by: David Heidelberg <david@ixit.cz>
Tested-by: Siavash Eliasi <siavashserver@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Revert "mesa: Wrap SSE4.1 code in #ifdef __SSE4_1__."

This reverts commit 8d3f739383fbdf671752fdec707f1c2b9b2aa6a3.

In the last commit we've updated our check to determine if the actual
code is buildable, rather than if the compiler acknowledges the option.
I.e. did anyone provide -mno-sse4.1 vs is my compiler too old.

Now this code will never be attemped to be build, in both cases.

Confirmed by building mesa with
export CFLAGS='-march=native -mno-sse4.1'
./configure && make

Tested-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
freedreno/a4xx: move where SP_FS_MRT_REGn is emitted

Addition of color fmt bitfield to this register (compared to a3xx) means
we need to re-emit if either prog or framebuffer state is dirty.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a4xx: implement mem->gmem (restore)

Support to restore gmem (tile buffer) (in case it wasn't glClear'd).

Signed-off-by: Rob Clark <robclark@freedesktop.org>
tgsi: fixup the string of VS_WINDOW_SPACE_POSITION

Tested-by: Nick Sarnie <commendsarnex@gmail.com>
gallium/util: add a window_space option to the passthrough vertex shader

Tested-by: Nick Sarnie <commendsarnex@gmail.com>
gallium/util: add a test for TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION

Not testable by OpenGL. Required by Nine.

This is an example of how to implement a piglit-like test using gallium only.
tgsi/ureg: simplify code for declaring properties

Tested-by: Nick Sarnie <commendsarnex@gmail.com>
radeonsi: implement TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION

Required by Nine.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
gallium: remove unused pipe_viewport_state::translate[3] and scale[3]

Almost all drivers ignore them.
dri/kms: Always zero out struct drm_mode_create_dumb

The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
specified, which has the effect that some kernel drivers do not consider
the .pitch and .size fields of struct drm_mode_create_dumb outputs only.
Instead they will use these as lower bounds and overwrite them only if
the values that they compute are larger than what userspace provided.

This works if and only if userspace initializes the fields explicitly to
either 0 or some meaningful value. However, if userspace just leaves the
values uninitialized and the struct drm_mode_create_dumb is allocated on
the stack for example, the driver may try to overallocate buffers.

Fortunately most userspace does zero out the structure before passing it
to the IOCTL, but there are rare exceptions. Mesa is one of them. In an
attempt to rectify this situation, kernel drivers are being updated to
not use the .pitch and .size fields as inputs. However in order to fix
the issue with older kernels, make sure that Mesa always zeros out the
structure as well.

Future IOCTLs should be more rigorously defined so that structures can
be validated and IOCTLs rejected if output fields aren't set to zero.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
pipe-loader: consolidate sources into Makefile.sources

Drop the unneeded subdir-objects.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
gallium: ship the gallium API headers

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
auxiliary: ship all files in the distribution tarball

 - Add all headers into Makefile.sources
 - Don't forget the target-helpers
 - Add the python scripts & the formats table/list (csv)
 - Temporary add vl/vl_winsys_dri.c to EXTRA_DIST until we rework the
way VL is build.
 - Add the following to EXTRA_DIST - they are included via the
generated u_indices_gen.c thus we should not add them to *SOURCES.
  indices/u_indices.c
  indices/u_unfilled_indices.c

XXX: Should we nuke gallivm/f.cpp ? It seems that no-one is using it.

v2: Rebase

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
targets: bundle all files in the tarball

We were missing a few files
 - The version scripts
 - Android & scons build scripts
 - A few headers.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
freedreno: add missing headers in Makefile.sources

... or autotools will fail to pick them up for the distribution tarball.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
gallium/auxiliary: Remove GALLIVM_CPP_SOURCES

Redundant.

Should fix ttps://bugs.freedesktop.org/show_bug.cgi?id=86330
gallium/auxiliary: Fix build without LLVM.

Trivial.
draw: Fix breakage due to removal pipe_viewport_state::translate[3] and scale[3].

Unfortunately no LLVM type was generated for pipe_viewport_state -- it
was being treated as a single floating point array --, so llvmpipe (and
any driver that relies on draw/llvm) got totally busted.