nouveau: fix nouveau_scratch_runout_release bo count underflow
nvc0/ir: fix lowering of textureGrad
nv50/ir/opt: don't lose saturation in tryCollapseChainedMULs
nvc0/ir: allow abs,neg source modifiers with ceil,floor,trunc
nv50: handle VP without inputs
mesa: bump version to 8.1.0 in configs/default
intel: Disable ARB_framebuffer_object in ES contexts

This patch removes ARB_framebuffer_object from the GLES1 and GLES2
extension lists in intel_extensions_es.c.

Fixes a crash in the Android browser on Ice Cream Sandwich.

The Android browser crashed because it did the following, which is legal
in GLES2 but not in ARB_framebuffer_object.
    glGenFramebuffers(1, &fb);
    glBindFramebuffer(GL_FRAMEBUFFER, fb);
    // render render render...
    glDeleteFramebuffers(1, &fb);
    // go do other stuff...
    glBindFramebuffer(GL_FRAMEBUFFER, fb);
    // This bind unexpectedly failed, and the app panics.

The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a
desktop GL extension) and GLES2 specs are incompatible. The ideal solution
to fix this is to create separate API entry points for glBindFramebuffer,
one for GL and the other for GLES2. But, until that work is complete,
disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem.

Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and
of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are
incompatible. Even though the functions have different names, the semantic
difference still results in a bug because both API calls are implemented
by a single function, _mesa_BindFramebufferEXT, which handles the semantic
difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1
contexts safely fixes this problem.

According to the ARB_framebuffer_object spec, the extension is an
amalgamation of
    EXT_framebuffer_object
    EXT_framebuffer_blit
    EXT_packed_depth_stencil
    EXT_framebuffer_multisample
By disabling this extension, however, no functionality is removed from
GLES1 and GLES2 contexts because 1) the first three extensions are
explicitly enabled in Intel's ES extension lists and 2) no functionality
of the last extension is exposed in an ES context.

Note: This is a candidate for the 8.0 branch.
See-also: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg21006.html
CC: Charles Johnson <charles.f.johnson@intel.com>
CC: Sean Kelley <sean.v.kelley@intel.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
i965: Fix mipmap offsets for HiZ and separate stencil buffers.

When rendering to a miplevel other than 0 within a color, depth,
stencil, or HiZ buffer, we need to tell the GPU to render to an offset
within the buffer, so that the data is written into the correct
miplevel.  We do this using a coarse offset (in pages), and a fine
adjustment (the so-called "tile_x" and "tile_y" values, which are
measured in pixels).

We have always computed the coarse offset and fine adjustment using
intel_renderbuffer_tile_offsets() function.  This worked fine for
color and combined depth/stencil buffers, but failed to work properly
when HiZ and separate stencil were in use.  It failed to work because
there is only one set of fine adjustment controls shared by the HiZ,
depth, and stencil buffers, so we need to choose tile_x and tile_y
values that are compatible with the tiling of all three buffers, and
then compute separate coarse offsets for each buffer.

This patch fixes the HiZ and separate stencil case by replacing the
call to intel_renderbuffer_tile_offsets() with calls to two functions:
intel_region_get_tile_masks(), which determines how much of the
adjustment can be performed using offsets and how much can be
performed using tile_x and tile_y, and
intel_region_get_aligned_offset(), which computes the coarse offset.

intel_region_get_tile_offsets() is still used for color renderbuffers,
so to avoid code duplication, I've re-worked it to use
intel_region_get_tile_masks() and intel_region_get_aligned_offset().

On i965 Gen6, fixes piglit tests
"texturing/depthstencil-render-miplevels 1024 X" where X is one of
(depth, depth_and_stencil, depth_stencil_single_binding, depth_x,
depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x).

On i965 Gen7, the variants of
"texturing/depthstencil-render-miplevels" that contain a stencil
buffer still fail, due to another problem: Gen7 seems to ignore the 3
LSB's of the tile_y adjustment (and possibly also tile_x).

v2: Removed spurious comments.  Added assertions to check
preconditions of intel_region_get_aligned_offset().

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
fbo: Only reuse depth/stencil attachments if the parameters match.

When the user attaches a texture to one of the depth/stencil
attachment points (GL_STENCIL_ATTACHMENT or GL_DEPTH_ATTACHMENT), we
check to see if the same texture is also attached to the other
attachment point, and if so, we re-use the existing texture
attachment.  This is necessary to ensure that if the user later
queries what is attached to GL_DEPTH_STENCIL_ATTACHMENT, they will not
receive an error.

If, however, the user attaches buffers to the two different attachment
points using different parameters (e.g. a different miplevel), then we
can't re-use the existing texture attachment, because it is pointing
to the wrong part of the texture.  This might occur as a transitory
condition if, for example, if the user attached miplevel zero of a
texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT, rendered to
it, and then later attempted to attach miplevel one of the same
texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT.

This patch causes Mesa to check that GL_STENCIL_ATTACHMENT and
GL_DEPTH_ATTACHMENT use the same attachment parameters before
attempting to share the texture attachment.

On i965 Gen6, fixes piglit tests
"texturing/depthstencil-render-miplevels 1024 depth_stencil_shared"
and "texturing/depthstencil-render-miplevels 1024
stencil_depth_shared".

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/Gen6: Work around GPU hangs due to misaligned depth coordinate offsets.

In i965 Gen6, Mesa has for a long time used the "depth coordinate
offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
render to miplevels other than 0.  Unfortunately, this doesn't work,
because these offsets must be aligned to multiples of 8, and miplevels
in the depth buffer are only guaranteed to be aligned to multiples of
4.  When the offsets aren't aligned to a multiple of 8, the GPU
sometimes hangs.

As a temporary measure, to avoid GPU hangs, this patch smashes the 3
LSB's of "depth coordinate offset X/Y" to 0.  This results in
incorrect rendering to mipmapped depth textures, but that seems like a
reasonable stopgap while we figure out a better solution.

(Note that we have only ever observed this GPU hang on Gen6 when HiZ
is enabled, so another possible stopgap would be to disable HiZ).

Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at
texture sizes that are not powers of 2.

Reviewed-by: Chad Verace <chad.versace@linux.intel.com>
i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.

In i965 Gen7, Mesa has for a long time used the "depth coordinate
offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
render to miplevels other than 0.  Unfortunately, this doesn't work,
because these offsets must be aligned to multiples of 8, and miplevels
in the depth buffer are only guaranteed to be aligned to multiples of
4.  When the offsets aren't aligned to a multiple of 8, the GPU
sometimes hangs.

As a temporary measure, to avoid GPU hangs, this patch smashes the 3
LSB's of "depth coordinate offset X/Y" to 0.  This results in
incorrect rendering to mipmapped depth textures, but that seems like a
reasonable stopgap while we figure out a better solution.

Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at
texture sizes that are not powers of 2.

Reviewed-by: Chad Verace <chad.versace@linux.intel.com>
radeon/llvm: Remove references to DebugFlag and isCurrentDebugType()

These weren't being used at all and they were causing build failures
when LLVM was built with NDEBUG defined and mesa was not.

https://bugs.freedesktop.org/show_bug.cgi?id=49110
r600g: Fix out of tree builds that use the LLVM backend

https://bugs.freedesktop.org/show_bug.cgi?id=49567
radeon/llvm: use bitcasts for integers

We're using float as default type, so basically for every instruction that
wants other types for dst/src operands we need to perform the bitcast
to/from default float. Currently bitcast produces no-op MOV instruction,
will be eliminated later.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: use integer comparison for IF

Replacing "float equal to 1.0f" with "int not equal to 0".
This should help for further optimization of boolean computations.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: fix ABS_i32 instruction lowering

Swap source operands.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: add support for v4i32

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: fix live-in handling for inputs

Set the input registers as live-in for entry basic block.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: add support for VertexID, InstanceID

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
radeon/llvm: add support for TXQ/TXF/DDX/DDY instructions

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>