radeon/llvm: add a pattern for fsqrt

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeon/llvm: add support for cos/sin intrinsic

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeon/llvm: use llvm intrinsic for flog2

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeon/llvm: use llvm fabs intrinsic

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeon/llvm: use floor intrinsic instead of llvm.AMDIL.floor

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeon/llvm: use ceil intrinsic instead of llvm.AMDIL.round.posinf

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
egl: Return EGL_BAD_MATCH for invalid profile attributes

Version 12 of the EGL_KHR_create_context spec changed this behavior.

NOTE: This is a candidate for the 9.0 branch
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/vs: Fix unit mismatch in scratch base_offset parameter.

move_grf_array_access_to_scratch() calculates scratch buffer offsets in
bytes.  However, emit_scratch_read/write() expects the base_offset
parameter to be measured in OWords.

As a result, a shader using a scratch read/write offset greater than
zero (in practice, a shader containing more than one variable in
scratch) would use too large an offset, frequently exceeding the
available scratch space.

This patch corrects the mismatch by removing spurious conversion from
OWords to bytes in move_grf_array_access_to_scratch().

This is based on a patch by Paul Berry.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: Implement register spilling.

To validate this code, I ran piglit -t vs quick.tests with the "go spill
everything" debugging code enabled.  There was only one regression:
glsl-vs-unroll-explosion simply ran out of registers.  This should be
fine in the real world, since no one actually spills every single
register.

NOTE: This is a candidate for the 9.0 branch. Even if it proves to have
bugs, it's likely better than simply failing to compile.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vs: Try again when we've successfully spilled a reg.

Before, we'd spill one reg, then continue on without actually register
allocating, then assertion fail when we tried to use a vgrf number as a
register number.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Add support for splitting virtual GRFs.

This should improve our ability to register allocate without spilling.
Unfortuantely, due to the live variable analysis being ignorant of loops, we
still have register allocation failures on some programs.

v2: Add more context to the comment explaining the function.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
svga: Add support for 16-bit per channel RGBA

Signed-off-by: Brian Paul <brianp@vmware.com>
svga: Remove wierd code which forces non-sRGB formats.

Signed-off-by: Brian Paul <brianp@vmware.com>
svga: don't use uninitialized framebuffer state

Only the first 'nr_cbufs' color buffers in the pipe_framebuffer_state are
valid.  The rest of the color buffer pointers might be unitialized.
Fixes a regression in the piglit fbo-srgb-blit test since changes in the
gallium blitter code.

NOTE: This is a candidate for the 9.0 branch (just to be safe).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
docs: start release notes file for 9.1
st/mesa: remove useless checking in reset_cache

It's always NULL here.

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: use transfer_inline_write in st_texture_image_data

Reviewed-by: Brian Paul <brianp@vmware.com>
softpipe: remove unused functions

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: use the renderbuffer chosen by core Mesa in CopyTexSubImage

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium: unify transfer functions

"get_transfer + transfer_map" becomes "transfer_map".
"transfer_unmap + transfer_destroy" becomes "transfer_unmap".

transfer_map must create and return the transfer object and transfer_unmap
must destroy it.

transfer_map is successful if the returned buffer pointer is not NULL.
If transfer_map fails, the pointer to the transfer object remains unchanged
(i.e. doesn't have to be NULL).

Acked-by: Brian Paul <brianp@vmware.com>