llvmpipe: Fix geometry shader token leak.

Trivial. Matches softpipe's code.
softpipe: don't assert when creating surfaces with multiple layers

We can't handle them yet, however we can safely just warn (we will
just render to first layer, which is fine since we can't handle
rendertarget system value neither).
Also make behavior more predictable with buffer surfaces
(it would sometimes hit bogus asserts because of the union in the surface,
instead create the surface but assert when trying to set a buffer
in the framebuffer).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: don't assert when trying to render to surfaces with multiple layers

instead just warn when creating the surface, rendering will simply happen
to first layer.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
tgsi: fix sample_d emit for arrays

Those cases were apparently forgotten.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
mesa: Fix FB blitting in case of zero size src or dst rect

Framebuffer blitting operation should be skipped if any of the
dimensions (width/height) of src/dst rect is zero.

V2: Move the dimension check after error checking in _mesa_BlitFramebuffer.

Fixes: fbblit(negative.nullblit.zeroSize) in Intel oglconform
https://bugs.freedesktop.org/show_bug.cgi?id=59495

Note: Candidate for all the stable branches.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
radeon/llvm: fix LLVM dependencies

Since commit 1c4f283151b191c51cbd76d7f304cc1fe7be3019 we obvious depend on this.

Signed-off-by: Christian König <christian.koenig@amd.com>
softpipe: Shrink context size.

- each softpipe_tex_tile_cache 50*64*64*4*4 = 3,276,800 bytes
- each softpipe_context has 3*32 softpipe_tex_tile_cache, i.e, each softpipe
  context is 314,572,800 bytes, i.e, 300MB

That is, in a 32bits process (around 3GB virtual memory max), we can
only fit 10 contexts.

This change is a short-term hack to shrink the context size.  Longer
term we'll need to change how the texture cache works.

Reviewed-by: Brian Paul <brianp@vmware.com>
scons: Define _ALLOW_KEYWORD_MACROS on MSVC builds.

scons/llvm.py defines inline globally to workaround issues with LLVM C
binding headers, so the only way to is to avoid
aggravating xkeycheck.h errors is to set _ALLOW_KEYWORD_MACROS.

This fixes MSVC 2012 build with LLVM.

Reviewed-by: Brian Paul <brianp@vmware.com>
i965: Simplify separate stencil check

The only format returned by _mesa_get_format_base_format() that
satisfies _mesa_is_depthstencil_format() is GL_DEPTH_STENCIL, so we
can simplify the check.
i965: Change fragment input related bitfields to 64-bit.

This patch updates the bitfields brw_context::wm.input_size_masks,
tracker::size_masks, and brw_wm_prog_key::proj_attrib_mask, all of
which are indexed by gl_frag_attrib, from 32-bit to 64-bit.

This paves the way for supporting geometry shaders, and for merging
the gl_frag_attrib and gl_vert_result enums.  The combination of these
two will require at least 55 bits in the bitfields.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
mtypes.h: Add new gl_varying_slot enum, and bitfield defines.

Future patches will make use of the enum.  It will eventually take the
place of the existing enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib, all of which represent essentially
the same information but using inconsistent values.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
mtypes.h: Modify gl_vert_result to refer to new gl_varying_slot enum.

This paves the way for eliminating the gl_vert_result enum entirely.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Replace gl_vert_result enum with gl_varying_slot.

This patch makes the following search-and-replace changes:

gl_vert_result -> gl_varying_slot
VERT_RESULT_* -> VARYING_SLOT_*

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
mtypes.h: Modify gl_geom_attrib to refer to new gl_varying_slot enum.

This paves the way for eliminating the gl_geom_attrib enum entirely.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Replace gl_geom_attrib enum with gl_varying_slot.

This patch makes the following search-and-replace changes:

gl_geom_attrib -> gl_varying_slot
GEOM_ATTRIB_* -> VARYING_SLOT_*
GEOM_BIT_* -> VARYING_BIT_*

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
mtypes.h: Modify gl_geom_result to refer to new gl_varying_slot enum.

This paves the way for eliminating the gl_geom_result enum entirely.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Replace gl_geom_result enum with gl_varying_slot.

This patch makes the following search-and-replace changes:

gl_geom_result -> gl_varying_slot
GEOM_RESULT_* -> VARYING_SLOT_*

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
mtypes.h: Modify gl_frag_attrib to refer to new gl_varying_slot enum.

This paves the way for eliminating the gl_frag_attrib enum entirely.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Get rid of _mesa_vert_result_to_frag_attrib().

Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function.  But we still need to be able to detect when a given vertex
output has no corresponding fragment input.  So it is replaced by a
new function, _mesa_varying_slot_in_fs(), which tells whether the
given varying slot exists as an FS input or not.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Get rid of _mesa_frag_attrib_to_vert_result().

Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>