r600/llvm: Allow arbitrary amount of temps in tgsi to llvm
glapi: Do not include dlfcn.h on Windows.

This patch fixes this MinGW build error.

  CC     glapi_gentable.lo
glapi_gentable.c:47:19: fatal error: dlfcn.h: No such file or directory

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers

Consider a typical game-style main loop which might be like this:

while (1) {
	draw_something();
	eglSwapBuffers();
}

In this case the game is relying on eglSwapBuffers to throttle to a sensible
frame rate. Previously this game would end up using three buffers even though
it should only need two. This is because Mesa decides whether to allocate a
new buffer in get_back_bo which would be before it has tried to read any
events from the compositor so it wouldn't have seen any buffer release events
yet.

This patch just moves the block for the frame callback to get_back_bo.
Typically the compositor will send a release event immediately after one of
the attaches so if we block for the frame callback here then we can be sure to
have completed at least one roundtrip and received that release event after
attaching the previous buffer before deciding whether to allocate a new one.

dri2_swap_buffers always calls get_back_bo so even if the client doesn't
render anything we will still be sure to block to the frame callback. The code
to create the new frame callback has been moved to after this call so that we
can be sure to have cleared the previous frame callback before requesting a
new one.
wayland: Add support for eglSwapInterval

The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.

The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers can be executed as often as necessary.
Instead it will do a sync request after the swap buffers. It will block for
sync complete event in get_back_bo instead of the frame callback. The
compositor is likely to send a release event while processing the new buffer
attach and this makes sure we will receive that before deciding whether to
allocate a new buffer.

If there are no buffers available then instead of returning with an error,
get_back_bo will now poll the compositor by repeatedly sending sync requests
every 10ms. This is a last resort and in theory this shouldn't happen because
there should be no reason for the compositor to hold on to more than three
buffers. That means whenever we attach the fourth buffer we should always get
an immediate release event which should come in with the notification for the
first sync request that we are throttled to.

When the compositor is directly scanning out from the application's buffer it
may end up holding on to three buffers. These are the one that is is currently
scanning out from, one that has been given to DRM as the next buffer to flip
to, and one that has been attached and will be given to DRM as soon as the
previous flip completes. When we attach a fourth buffer to the compositor it
should replace that third buffer so we should get a release event immediately
after that. This patch therefore also changes the number of buffer slots to 4
so that we can accomodate that situation.

If DRM eventually gets a way to cancel a pending page flip then the compositors
can be changed to only need to hold on to two buffers and this value can be
put back to 3.

This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
llvmpipe: clamp fragment shader depth write to the current viewport depth range.

With this patch, generate_fs_loop will clamp any fragment shader depth writes
to the viewport's min and max depth values. Viewport selection is determined
by the geometry shader output for the viewport array index. If no index is
specified, then the default viewport index is zero. Semantics for this path
can be found in draw_clamp_viewport_idx and lp_clamp_viewport_idx.

lp_jit_viewport was created to store viewport information visible to JIT code,
and is validated when the LP_NEW_VIEWPORT dirty flag is set.

lp_rast_shader_inputs is responsible for passing the viewport_index through
the rasterizer stage to fragment stage (via lp_jit_thread_data).

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
nv50: TXF already has integer arguments, don't try to convert from f32

Fixes the texelFetch piglit tests

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: make sure nvd7 gets NVC8_3D_CLASS as well

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nv50: enable h264 and mpeg4 for nv98+ (vp3, vp4.0)

Create the ref_bo without any storage type flags set for now. The issue
probably arises from our use of the additional buffer space at the end
of the ref_bo. It should probably be split up in the future.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Martin Peres <martin.peres@labri.fr>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
nouveau/video: update h264 picparm field names based on usage

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
nouveau/video: update a few more h264 picparm field names

Based on comments by Benjamin Morris <bmorris@nvidia.com> in
http://lists.freedesktop.org/archives/nouveau/2013-December/015328.html

This adds setting of is_long_term, and updates a few field names we were
unclear about.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
r300/compiler/tests: Fix segfault

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

CC: "9.2" "10.0" <mesa-stable@lists.freedesktop.org>
r300/compiler/tests: Fix line length check in test parser

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

CC: "9.2" "10.0" <mesa-stable@lists.freedesktop.org>
i965/blorp: Improve fast color clear comment.

Clarify the fact that we only optimize full buffer clears using fast
color clear, and why.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Document conventions for counting layers in 2D multisample buffers.

The "layer" parameters used in blorp, and the
intel_renderbuffer::mt_layer field, represent a physical layer rather
than a logical layer.  This is important for 2D multisample arrays on
Gen7+ because the UMS and CMS multisample layouts use N physical
layers to represent each logical layer, where N is the number of
samples.

Also add an assertion to blorp to help catch bugs if we fail to follow
these conventions.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Don't try to use HW blitter for glCopyPixels() when multisampled.

The hardware blitter doesn't understand multisampled layouts, so
there's no way this could possibly succeed.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen7+: Disentangle MSAA layout from fast clear state.

This patch renames the enum that's used to keep track of fast clear
state from "mcs_state" to "fast_clear_state", and it removes the enum
value INTEL_MCS_STATE_MSAA (which previously meant, "this is an MSAA
buffer, so we're not keeping track of fast clear state").  The only
real purpose that enum value was serving was to prevent us from trying
to do fast clear resolves on MSAA buffers, and it's just as easy to
prevent that by checking the buffer's msaa_layout.

This paves the way for implementing fast clears of MSAA buffers.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/blorp: Get rid of redundant num_samples blorp param.

Previously, brw_blorp_params contained two fields for determining
sample count: num_samples (which determined the multisample
configuration of the rendering pipeline) and dst.num_samples (which
determined the multisample configuration of the render target
surface).  This was redundant, since both fields had to be set to the
same value to avoid rendering errors.

This patch eliminates num_samples to avoid future confusion.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/blorp: allow multisample blorp clears

Previously, we didn't do multisample blorp clears because we couldn't
figure out how to get them to work.  The reason for this was because
we weren't setting the brw_blorp_params num_samples field consistently
with dst.num_samples.  Now that those two fields have been collapsed
down into one, we can do multisample blorp clears.

However, we need to do a few other pieces of bookkeeping to make them
work correctly in all circumstances:

- Since blorp clears may now operate on multisampled window system
  framebuffers, they need to call
  intel_renderbuffer_set_needs_downsample() to ensure that a
  downsample happens before buffer swap (or glReadPixels()).

- When clearing a layered multisample buffer attachment using UMS or
  CMS layout, we need to advance layer by multiples of num_samples
  (since each logical layer is associated with num_samples physical
  layers).

Note: we still don't do multisample fast color clears; more work needs
to be done to enable those.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/blorp: Refactor code for computing fast clear align/scaledown factors.

This will make it easier to add fast color clear support to MSAA
buffers, since they have different alignment and scaling requirements.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen7+: Implement fast color clears for MSAA buffers.

Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>