Enable it in the evergreen_context_draw if needed.
Same as already done in the r600_context_draw for r6xx/r7xx.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

BURST_COUNT is clipped with ARRAY_SIZE, so set it to the max value
to avoid clipping.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Tested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Matt Turner <mattst88@gmail.com>

libglapi.so, libGL.so, libGLESv2.so, libGLESv1_CM.so must all
come from the same version of Mesa or bad things may happen.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>

Fixes glsl-const-folding-01. inversesqrt(1.0) != 1.0 was evaluating as
true.

Signed-off-by: Matt Turner <mattst88@gmail.com>

When the framebuffer has separate depth and stencil buffers, and HiZ is
not enabled on the depth buffer, mark the framebuffer as unsupported. This
happens when trying to create a framebuffer with Z16/S8 because we haven't
enabled HiZ on Z16 yet.

Fixes gles2conform test stencil8.

Note: This is a candiate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44948
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed--by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

This loosens the format validation in glBlitFramebuffer. When blitting
depth bits, don't require an exact match between the depth formats; only
require that the two formats have the same number of depth bits and the
same depth datatype (float vs uint). Ditto for stencil.

Between S8_Z24 buffers, the EXT_framebuffer_blit spec allows
glBlitFramebuffer to blit the depth and stencil bits separately. So I see
no reason to prevent blitting the depth bits between X8_Z24 and S8_Z24 or
the stencil bits between S8 and S8_Z24. However, we of course don't want
to allow blitting from Z32 to Z32_FLOAT.

Fixes Piglit fbo/fbo-blit-d24s8 on Intel drivers with separate stencil
enabled.

The problem was that, on Intel drivers with separate stencil, the default
framebuffer has separate depth and stencil buffers with formats X8_Z24 and
S8. The test attempts to blit the depth bits from a S8_Z24 buffer into the
default framebuffer.

v2: Check that depth datatypes match.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44665
Note: This is a candidate for the 8.0 branch.
Reported-by: Xunx Fang <xunx.fang@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

NOTE: This is a candidate for the 8.0 branch.

The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used since
the Outputs array was smaller than that maximum.

v2: added assertions

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: Paul Berry <stereotype441@gmail.com>

So it appears R600s (except rv670) do AR handling different using a different
opcode. This patch fixes up r600g to work properly on r600.

This fixes ~100 piglit tests here (in GLSL1.30 mode) on rv610.

v3: add index_mode as per the docs.

This still fails any dst relative tests for some reason I can't quite see yet,
but it passes a lot more tests than without.

v4: add a nop after dst.rel this could be improved using a second pass,
where we only insert nops if two instructions are sure to collide.
The docs say r600, rv610, rv630 needs this, and not rv670, rs780, rs880,
need AMD to confirm rv620, rv635.

v5: add is_nop_inst.

NOTE: This is a candidate for stable branches.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Caused by commit 7a1e941ebe.

Use a bitmask approach to compute gl_array_object::_MaxElement.
To make this work correctly depending on the shader type actually used,
make use of the newly introduced typed bitmask getters.
With this change I gain about 5% draw time on some osgviewer examples.

Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>

Depending on the installed shader type, different arrays are used
from gl_array_object. Provide helper functions that compute
the bitmask of these arrays that are finally enabled for a given
shader type. The will be used in a followup change.

Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>

Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>

Commit ede60bc467 (glsl: Add isinf() and
isnan() builtins) uses "+INF" in the .ir file to represent infinity.
This worked on C99-compliant compilers, since the s-expression reader
uses strtod() to read numbers, and C99 requires strtod() to understand
"+INF".  However, it didn't work on non-C99-compliant compilers such
as MSVC.

This patch modifies the s-expression reader to explicitly check for
"+INF" rather than relying on strtod() to support it.

This is a candidate for the 8.0 branch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44767
Tested-by: Morgan Armand <morgan.devel@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

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

To fix failed assertions when calling glCopyBufferSubData().

svga_texture() asserts that the resource is a texture.  Simply move the
calls to svga_texture() after the code that handles non-texture copies
so that we don't call it with non-texture resources.

Fixes glean bufferObject failure.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

Two assignments to num_immediates were missing in
get_pixel_transfer_visitor() and get_bitmap_visitor().
The uninitialized value led to valgrind errors and crashes in some
cases.

Added new assertions to catch future problems in this area.  Also
changed num_immediates to unsigned to avoid signed/unsigned
comparison warnings.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

The default access flags for OpenGL ES (via GL_OES_map_buffer) and
desktop OpenGL are different.  The code previously tried to handle
this, but the decision was made at compile time.  Since the same
driver binary can be used for both OpenGL ES and desktop OpenGL, the
decision must be made at run-time.

This should fix bug #44433.  It appears that the test case does
various map and unmap operations and inspects the state of the buffer
object around each.  When it sees that GL_BUFFER_ACCESS does not match
its expectations, it fails.

NOTE: This is a candidate for release branches.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433

If we don't find an exact PIPE_FORMAT_x for a GL_(COMPRESSED)_RED/RG format,
try uncompressed formats.  We were already doing this for the RGB(A) formats.

Fixes piglit arb_texture_compression-internal-format-query test.

NOTE: This is a candidate for the stable branches.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

Otherwise the fence will never arrive.
Also check for a NULL i915->batch.

NOTE: This is a candidate for the 8.0 branch.

NOTE: This is a candidate for the 8.0 branch.

msg_type moved by a bit, so the message type was being disassembled
incorrectly.  In particular, render target writes were showing up as
"OWORD block write".

NOTE: This is a candidate for stable release branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

Compared to sampler_gen5, simd_mode shifted by a bit and msg_type grew
by a bit.  So we were printing slightly incorrect numbers.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

Both the VF and VS share space in the URB.  First, the VF stores
attributes (shader inputs) there.  The VS then reads the attributes,
executes, and reuses the space to store varyings (shader outputs).

Thus, we need to calculate the amount of URB space necessary for inputs,
outputs, and pick whichever is greater.

The old VS backend correctly did this (brw_vs_emit.c:408), but the new
VS backend only considered outputs.

Fixes vertex scrambling in GLBenchmark PRO on Ivybridge.

NOTE: This is a candidate for the 8.0 branch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41318
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

In the following scenario:
- CreateContext C1
- MakeCurrent C1
- DestroyContext C1 (does not actually destroy the first context, postponed
 until the next MakeCurrent)
 - CreateContext C2
 - MakeCurrent C2
MakeCurrent will call flush on a half destroyed context, leading to crashes.
Since the other paths (destroy and makecurrent) already flush the context,
there is no need to flush here, so we remove this useless flush front call.

This fixes GPU crashes with Chrome and gallium drivers.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41216
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43212
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43250
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Jin Yang <jin.a.yang@intel.com>

The entry point is supposed to validate that the EGLImage is suitable for
the passed in usage flags, but that was never implemented.

v2: Don't flag the format as being HiZ ready (there's DRI2 handshake
    pain to go through).

Fixes piglit gl-3.0-required-sized-texture-formats

NOTE: This is a candidate for the 8.0 branch.

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

This is required for Z16 support for texturing, which is the first
thing to have a horizontal alignment of 8.  Renderbuffers don't need
it, since they're always set up as the only mip level, but do it for
completeness anyway.

NOTE: This is a candidate for the 8.0 branch.

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

This field is actually set up above.

NOTE: This is a candidate for the 8.0 branch, to avoid conflicts.

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

NOTE: This is a candidate for the 8.0 branch.

I copy-and-pasted the thing I was allocating for as the context, so
the first time it would be NULL (root of a ralloc context) and they'd
chain off each other from then on.

NOTE: This is a candidate for the 8.0 branch.

NOTE: This is a candidate for the 8.0 branch.

NOTE: This is a candidate for the 8.0 branch.

This statement got duplicated above, probably in a rebase resolution,
so we never freed the extra one.

NOTE: This is a candidate for the 8.0 branch.

Fixes a leak of almost 200kb on a minimal shader_runner program
(algebraic-add-add-1).

NOTE: This is a candidate for the 8.0 branch.

This fixes a memory leak on i965 context destruction.

NOTE: This is a candidate for the 8.0 branch.

The legal range for the device is apparently [-16.0, +15.0].
Limiting the range to [-15, +15] fixes piglit's lodbias test.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

The interaction between the mipmap lod min/max limits and the texture
base/max level limits is kind of tricky.  Changing the base level
didn't work as expected before.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

This makes lod clamping more consistent with other drivers.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

when mapping renderbuffers or texture images.

NOTE: This is a candidate for the 8.0 branch.

Update the dd.h docs to indicate that GL_MAP_INVALIDATE_RANGE_BIT
can be used with GL_MAP_WRITE_BIT when mapping renderbuffers and
texture images.

Pass the flag when mapping texture images for glTexImage, glTexSubImage,
etc.  It's up to drivers whether to actually make use of the flag.

NOTE: This is a candidate for the 8.0 branch.

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

To try to use less tex memory and maybe get better performance.
Spotted by Roland Scheidegger.

NOTE: This is a candidate for the 8.0 and 7.11 branches.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

The i965 driver advertises GL_ARB_texture_float and GL_ARB_texture_rg
support but the ctx->TextureFormatSupported[] table entries for
MESA_FORMAT_R_FLOAT32 and MESA_FORMAT_RGBA_FLOAT32 are false on gen 4
hardware.  So the case for GL_R32F would fail and we'd print an
implementation error.

This patch adds more Mesa tex format options for GL_R32F and other R/G
formats so we fall back to 16-bit formats when 32-bit formats aren't
available.

Eric made the same fix in commit 6216a5b4 for the non R/G formats.

v2: try 16-bit formats before 32-bit formats and try RG formats before
RGBA where possible.

This should fix https://bugs.freedesktop.org/show_bug.cgi?id=44039

NOTE: This is a candidate for the 8.0 and 7.11 branches.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

* BePC, BeBox, BeMac for Haiku.
* Add sparc architecture as Mesa looks for it.

Signed-off-by: José Fonseca <jfonseca@vmware.com>