i965/fs: initialize src as reg_undef for texture opcodes on Gen5/6.

Commit 07af0ab changed fs_inst to have 0 sources for texture opcodes
in emit_texture_gen5 (Ironlake, Sandybrige) while fs_generator still
uses a single source from brw_reg struct. Patch sets src as reg_undef
which matches the behavior before the constructor got changed.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79534
i965/fs: initialize src as reg_undef for texture opcodes on Gen4.

Untested.
i965: Don't include mtypes.h in brw_disasm.c

It's not used.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Make gen7_pi field of brw_instruction use unsigned instead of GLuint

Nothing else uses GL-types here.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
glx: Fix build in GLX_DIRECT_RENDERING !GLX_USE_APPLEGL !GLX_USE_DRM case

Some untangling to fix building in the dri_platform=none, --enable-driglx-direct
case, where only driswast can be used.

Turn the test for including the glXGetScreenDriver()/glXGetScreenDriver()
interface used by xdriinfo from !GLX_USE_APPLEGL into a positive form, as it is
only useful when dri_platform=drm

Add additional GLX_USE_DRM tests so DRI[123] renderers are only used when
dri_platform=drm

Note that swrast and indirect must still be disabled in the APPLEGL case at the
moment, which makes things more complex than they need to be.  More untangling
is needed to allow that

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
configure: Always default to --enable-driglx-direct

Always default to --enable-driglx-direct, now that will build driswrast, but
won't try to use dri[123] on platforms which don't have that.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
r600g,radeonsi: implement PIPE_QUERY_TIMESTAMP_DISJOINT

v2 Marek: set the query result correctly

Signed-off-by: David Heidelberger <david.heidelberger@ixit.cz>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
configure: Only check for OpenCL without LLVM when the latter is certain

LLVM is enabled by default for some architectures, but the test was failing
before that.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
mesa: Fix substitution of large shaders

Signed-off-by: Cody Northrop <cody@lunarg.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
r600g/compute: Fixing a typo and some indentation

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Adding checks for NULL after CALLOC

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Add more NULL checks

In this case, NULL checks are added to compute_memory_grow_pool,
so it returns -1 when it fails. This makes necesary
to handle such cases in compute_memory_finalize_pending
when it is needed to grow the pool

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Tidy a bit compute_memory_finalize_pending

Explanation of the changes, as requested by Tom Stellard:

Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)

BEFORE:
If need is positive or 0:
    we calculate need += 1024 - (need % 1024), which is like
        cealing to the nearest multiple of 1024, for example
        0 goes to 1024, 512 goes to 1024 as well, 1025 goes
        to 2048 and so on. So now need is always possitive,
        we do compute_memory_grow_pool, check its output
        and continue.

If need is negative:
    we calculate need += 1024 - (need % 1024), in this case
        we will have negative numbers, and if need is
        [-1024:-1] 0, so now we take the else, recalculate
        need as need = pool->size_in_dw / 10 and
        need += 1024 - (need % 1024), we do
        compute_memory_grow_pool, check its output and continue.

AFTER:
If need is positive or 0:
    we jump the if, calculate need += 1024 - (need % 1024)
        compute_memory_grow_pool, check its output and continue.

If need is negative:
    we enter the if, and need is now pool->size_in_dw / 10.
        Now we calculate need += 1024 - (need % 1024)
        compute_memory_grow_pool, check its output and continue.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Cleanup of compute_memory_pool.h

Removed compute_memory_defrag declaration because it seems
to be unimplemented.

I think that this function would have been the one that solves
the problem with fragmentation that compute_memory_finalize_pending has.

Also removed comments that are already at compute_memory_pool.c

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: align items correctly

Now, items whose size is a multiple of 1024 dw won't leave
1024 dw between itself and the following item

The rest of the cases is left as it was

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Use %u as the unsigned format

This fixes an issue when running cl-program-bitcoin-phatk
piglit test where some of the inputs have negative values

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
glsl: Move definition of exec_node member functions out of the struct.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Move definition of exec_list member functions out of the struct.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add C API for exec_node.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add C API for exec_list.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>