mesa: Don't round-trip integer texture data through a floating point temp.

This was losing bits of precision.  Fixes (with the previous commits):
piglit EXT_texture_integer/getteximage-clamping
piglit EXT_texture_integer/getteximage-clamping GL_ARB_texture_rg
oglc advanced.mipmap.upload

Regresses oglc negative.typeFormatMismatch.teximage from fail to
abort, because it's been hitting texstore for a format/type combo that
shouldn't happen.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 5f65598cc79eccd38bf7f95ab167ed62e575daf2)

mesa: When unpacking signed integer pixel data, don't clamp to 0.

In the core, we always treat spans of int/uint data as uint, so this
extract function was truncating storage of integer pixel data to a n
int texture to (0, max_int) instead of (min_int, max_int).  There is
probably missing code for handling truncation on conversion between
pixel formats, still, but this does improve things.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit dadbec1e90415f0744eb91e684bf9d7496f474c0)

mesa: Add clamping for packing of integer data.

Mostly fixes piglit EXT_texture_integer/getteximage-clamping.  The
remaining failure involves precision loss on storing of int32 texture
data (something I knew was an issue, but wasn't trying to test).

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 8b97bb02fb1a55a6b0fe558ea1eb97bb4dae0347)

mesa: Add missing format unpack for some integer texture formats.

This cut and paste is pretty awful.  I'm tempted to do a lot of this
using preprocessor tricks for customizing the parameter type from a
template function, but that's just a different sort of hideous.

Fixes 8 Intel oglconform int-textures cases.

NOTE: This is a candidate for the 8.0 branch.
v2: Add alpha formats, too.

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit de24ccabd6494125e10017e0914b3298ea3791ea)

i965: Don't allow rendering to non-GL_RED/RG/RGBA integer textures.

Fixes piglit EXT_texture_integer/fbo-blending.
(cherry picked from commit 3a8cf3357abb50d4ee11cfb801f965e3df7592fb)

intel: Pass the gl_renderbuffer to render_target_supported() vtable method.

I'm going to want to go looking at it for an integer texture fix.

NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 796f44d77906342e5912e7da6bdba1ba86bab9f0)

intel: Make a renderbuffer wrapping a texture have the same _BaseFormat.

Otherwise, when you asked for the _BaseFormat of an rb wrapping a
GL_RGB texture, you got GL_RGBA because that's what we were storing
the texture data as.

NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 7cac88679bb600f35694e91859c4682c04c32f7a)

intel: Simplify intel_renderbuffer_update_wrapper() by passing in the image.

NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit b73f5df6483b2e37235b258f705944321ee617f5)

intel: Drop intel_wrap_miptree().

Most of this function was just calling
intel_renderbuffer_update_wrapper(), which was called immediately
afterwards in the only caller.

NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 74484c5d411788c855cf91a2017d763d6a8fb4f2)

i965: fix inverted point sprite origin when rendering to FBO

When rendering to FBO, rendering is inverted. At the same time, we would
also make sure the point sprite origin is inverted. Or, we will get an
inverted result correspoinding to rendering to the default winsys FBO.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44613

NOTE: This is a candidate for stable release branches.

v2: add the simliar logic to ivb, too (comments from Ian)
    simplify the logic operation (comments from Brian)

v3: pick a better comment from Eric
    use != for the logic instead of ^ (comments from Ian)

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit eaf360e5bffc5630789367020252cd12fe586177)

i965/fs: Fix rendering corruption in unigine tropics.

We were allocating registers into the MRF hack region, resulting in
sparkly renering in a few of the scenes.  We could do better
allocation by making an MRF class, having MRFs conflict with the
corresponding GRFs, and tracking the live intervals of the "MRF"s and
setting up the conflicts.  But this is way easier for the moment.

NOTE: This is a candidate for the 8.0 branch.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e910241e9754b6e673ed0fc3133c8b1de56e76c7)

intel: Avoid divide by zero for very small linear blits

If size is small (such as 1),

   pitch = ROUND_DOWN_TO(MIN2(size, (1 << 15) - 1), 4);

makes pitch = 0.  Then

   height = size / pitch;

causes a division-by-zero exception.  If pitch is zero, set height to
1 and avoid the division.

This fixes piglit's bin/getteximage-formats test and glean's
bufferObject test.

NOTE: This is a candidate for the 8.0 release branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44971
(cherry picked from commit d59466279e45a1e9c3f9081f72fedbdf961afbe1)

intel: Remove num_mapped_regions assertion from _intel_batchbuffer_flush

There are cases where a buffer can be mapped while another buffer is
flushed.  This can happen in the CopyPixels meta-op path for piglit's
fbo-mipmap-copypix.  After some discussion with Eric, it seems this
assertion is no longer necessary, and it has always been too strict.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 65b096aeddd9b45ca038f44cc9adfff86c8c48b2)

intel: FBOs with texture border are unsupported

FBOs differ from textures in a significant way.  With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].

With an FBO, the pixel at (0,0) is in the border.  The
ARB_framebuffer_object spec says:

    "If the attached image is a texture image, then the window
    coordinates (x[w], y[w]) correspond to the texel (i, j, k), from
    figure 3.10 as follows:

                           i = (x[w] - b)

                           j = (y[w] - b)

                           k = (layer - b)

    where <b> is the texture image's border width..."

Since the border doesn't exist, we can never render any pixels in the
correct location.  Just mark these FBOs FRAMEBUFFER_UNSUPPORTED.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42336
(cherry picked from commit 87b4c9b322dabeba7c9a9d02e9efefd2c89e6625)

glcpp: Fix so that trailing punctuation does not prevent macro expansion

The trick here is that flex always chooses the rule that matches the most
text. So with a input text of "two:" which we want to be lexed as an
IDENTIFIER token "two" followed by an OTHER token ":" the previous OTHER
rule would match longer as a single token of "two:" which we don't want.

We prevent this by forcing the OTHER pattern to never match any
characters that appear in other constructs, (no letters, numbers, #,
_, whitespace, nor any punctuation that appear in CPP operators).

Fixes bug #44764:

GLSL preprocessor doesn't replace defines ending with ":"
https://bugs.freedesktop.org/show_bug.cgi?id=44764

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable release branches.
(cherry picked from commit 7ab1c7f7926c75a07f33eb149d0fc17dcfaffd5e)

gallium/dri: Handle xserver that doesn't send needless DRI2 invalidate events

Ever since xserver commit 531869448d07e00ae241120b59f3aaaa5709d59c,
the server no longer sends invalidate events to clients, unless they
have performed a GetBuffers request since the drawable was last
invalidated.

If the drawable gets invalidated immediately after the GetBuffers
request was processed by the X server, it's possible that Xlib
will process the invalidate event while waiting for the GetBuffers
reply. So the server, thinking the client knows that the buffers
are invalid, is waiting for another GetBuffers request before
sending any more invalidate events. The client, on the other hand,
believes the buffers to be valid, and thus is expecting to receive
another invalidate event before it has to send another GetBuffers
request. The end result is that the client never again sends
a GetBuffers request.

To avoid this problem, take a snapshot of the lastStamp before
doing GetBuffers, and retry if the snapshot and the current
lastStamp no longer match after the GetBuffers reply has been
processed.

Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 0fcc518964223d9baaa2b45e80afeb800beb872f)

gallium/postprocess: move declarations before code

To fix MSVC build.
(cherry picked from commit 8cbe699c0dd9b8d4accf1eaa570689f813aa3c2f)

gallium/postprocess: Just to be safe, reference all buffers from outside

Even though it should be safe to use them for one frame, better be sure.
Suggested by Michael Dänzer.

NOTE: This is a candidate for the 8.0 stable branch.

Signed-off-by: Lauri Kasanen <cand@gmx.com>
(cherry picked from commit 81938d2137a7a65521ca5a3cd7180902d063c5c0)

gallium/postprocess: Fix depth logic

This prevents a possible lapse of the depth buffer - the situation where
the app and pp have different depth buffers.

NOTE: This is a candidate for the 8.0 stable branch.

Signed-off-by: Lauri Kasanen <cand@gmx.com>
(cherry picked from commit c5976017e31828dd67fb54e8c11b863fffcac70b)

gallium/postprocess: Proper reference counting of pp_jimenezmlaa depth buffer.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40776

NOTE: This is a candidate for the stable branches.
(cherry picked from commit 7219af5ec184d4f92682e75f3d992ae048005d6a)

i965/gen6: Fix segfault in transform feedback to DYNAMIC_DRAW buffers.

When storing data in a buffer of type DYNAMIC_DRAW, we don't create a
drm_intel_bo for it; instead we store the data in system memory and
defer allocation of the GPU buffer until it is needed.  Therefore, in
brw_update_sol_surface(), we can't just consult the "buffer" field of
the intel_buffer_object structure; we need to call
intel_bufferobj_buffer() to ensure that the deferred allocation
occurs.

This parallels a similar fix for gen7 (see commit ba6f4c9).

Fixes piglit test EXT_transform_feedback/buffer-usage on gen6.

This is a candidate for the 8.0 release branch.

Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 6bc08ee56991ac3ca0fa0728c3907835282332b8)

i965/vs: Fix bogus assertion in emit_block_move()

i965 processes assignments of whole structures using
vec4_visitor::emit_block_move, a recursive function which visits each
element of a structure or array (to arbitrary nesting depth) and
copies it from the source to the destination.  Then it increments the
source and destination register numbers so that further recursive
invocations will copy the rest of the structure.  In addition, it sets
the swizzle field for the source register to an appropriate value of
swizzle_for_size(...) for the size of each element being copied, so
that later optimization passes won't be fooled into thinking that
unused vector elements are live.

This all works fine.  However, emit_block_move also contains an
assertion to verify, before setting the swizzle field for the source
register, that the source register doesn't already contain a
nontrivial swizzle.  The intention is to make sure that the caller of
emit_block_move hasn't already done some swizzling of the data before
the call, which emit_block_move would then counteract when it
overwrites the swizzle field.  But the assertion is at the lowest
level of nesting of emit_block_move, which means that after the first
element is copied, instead of checking the swizzle field set by the
caller, it checks the swizzle field used when moving the previous
element.  That means that if the structure contains elements of
different vector sizes (which therefore require different swizzles),
the assertion will erroneously fire.

This patch moves the assertion from emit_block_move to the calling
function, vec4_visitor::visit(ir_assignment *).  Since the caller is
non-recursive, the assertion will only happen once, and won't be
fooled by emit_block_move's modification of the swizzle field.

This patch also reverts commit fe006a7 (i965/vs: Fix swizzle related
assertion), which attempted to fix the bug by making the assertion
more lenient, but only worked properly for structures, arrays, and
matrices in which each constituent vector is the same size.

This fixes the problem described in comment 9 of
https://bugs.freedesktop.org/show_bug.cgi?id=40865.  Unfortunately, it
doesn't fix the whole bug, since the test in question is also failing
due to lack of register spilling support in the VS.

Fixes piglit test vs-assign-varied-struct.  No piglit regressions on
Sandy Bridge.

This is a candidate for the 8.0 release branch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40865#c9
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e2274aa7398d6d710683c1a2518353750700bcc0)

mesa: Fix display list handling for GL_EXT_framebuffer_multisample.

From the extension spec:

    Added to section 5.4, as part of the discussion of which commands
    are not compiled into display lists:

    "Certain commands, when called while compiling a display list, are
    not compiled into the display list but are executed immediately.
    These are: ..., RenderbufferStorageMultisampleEXT..."

Fixes piglit EXT_framebuffer_multisample/dlist.

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 3d8c27f882b852ada86aac99a54fdb57d98a79ac)

mesa: Fix display list handling for EXT_framebuffer_object.

Noticed when handling a similar problem in EXT_framebuffer_multisample.

From the EXT_framebuffer_object spec:

    Added to section 5.4, as part of the discussion of which commands
    are not compiled into display lists:

    "Certain commands, when called while compiling a display list, are
    not compiled into the display list but are executed immediately.
    These are: ..., GenFramebuffersEXT, BindFramebufferEXT,
    DeleteFramebuffersEXT, CheckFramebufferStatusEXT,
    GenRenderbuffersEXT, BindRenderbufferEXT, DeleteRenderbuffersEXT,
    RenderbufferStorageEXT, FramebufferTexture1DEXT,
    FramebufferTexture2DEXT, FramebufferTexture3DEXT,
    FramebufferRenderbufferEXT, GenerateMipmapEXT..."

Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 25dd80555d895fbe98e8f8099283992d350f22a2)

mesa: fix maximum allowed proxy texture size condition

width, height parameter in glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 << (ctx->Const.MaxTextureLevels - 1)

Texture border is anyway stripped out before it is given to intel
or gallium drivers.

This patch fixes Intel oglconform test case: max_values
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970

Note: This is a candidate for mesa 8.0 branch.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit 15986d21ebaaeedb234b066edba5cf7f6ea87a3c)

mesa: set clamp bit in glGetTexImage for GL_UNSIGNED_NORMALIZED

Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA

Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
https://bugs.freedesktop.org/show_bug.cgi?id=40864

NOTE: This is a candidate for the 8.0 branch

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 5665b5cc31da70e833f80e7a17bfa034d2f7ba44)

mesa: Fix copy-and-paste error in _mesa_pack_rgba_span_float

GL_RG_INTEGER only has two components, not three.  I'll be surprised
if anyone ever tries to glReadPixels(..., GL_SHORT, GL_RG_INTEGER,
...).  This was found by inspection.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 2e8f8cb383320b83ba5d85c27808ac2d841834e6)

mesa: Fix copy-and-paste bug in do_row_3D

Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
(cherry picked from commit 5c341b7df3c1058d586629394e53e9e26ae2cc01)

mesa: Convert colors if span ChanType and renderbuffer data type don't match

This is a partial revert of f9874fe.  It turns out that the types
don't always match.  Specifically, this can happen when doing
glCopyPixels from a float FBO to a RGBA8 FBO.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 660ed923ded3552e023ef8c3dd9f92e6792f1bd2)

mesa: Set the gl_array_object::ARBsemantics flag at the right time

With 0963990 the flag was only set when Bind created the object.  In
all cases where ::ARBsemantics could be true, this path never
happened.  Instead, add a _Used flag to track whether a VAO has ever
been bound.  On the first Bind, set the _Used flag, and set the
ARBsemantics flag to the correct value.

NOTE: This is a candidate for release branches.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45423
(cherry picked from commit e06b1c65bc576a9b239841cbe3a8a8c2d6a8d09f)

mesa: Add unpack_uint_z_row support for floating-point depth buffers

This is a hack, and it will result in incorrect rendering.  However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.

The real solution is to add a zf field to SWspan to store float Z
values.  When a float depth buffer is involved, swrast should also
populate the zf field.  I'll consider this post-8.0 work.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit af1477b088448aeca762f515410c80054cb225b9)

mapi/glapi: Never use a generic no-op entry-point on Windows.

When GLAPIENTRY is __stdcall (ie Windows), the stack is popped by the
callee making the number/type of arguments significant, therefore
using a generic no-op causes stack corruption for many entry-points.

NOTE: This is a candidate for the 8.0 branch.

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

meta: Fallback for glBlitFramebuffer from a multisample surface

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44818
(cherry picked from commit b48d4b64e97f48dcf0aef1b6f7bc333c309cc183)

intel: Fix accum buffer mapping since the swrast rework.

A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum test.  Just look at the swrast renderbuffer pointer
for handling swrast rbs.
(cherry picked from commit 42e9936ce6bcac9f863b2f85978489e4f804e927)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45428

osmesa: set RefCount = 1 in new_osmesa_renderbuffer()

This was lost during the renderbuffer overhaul work.  Fixes a failed
refcount assertion.
(cherry picked from commit 3fc6e4e0254c0bfb643439952f2ceb55193010e7)

osmesa: Fix osmesa_context.DataType type.

Fixes these GCC warnings.
osmesa.c: In function ‘osmesa_renderbuffer_storage’:
osmesa.c:417: warning: comparison is always false due to limited range of data type
osmesa.c:423: warning: comparison is always false due to limited range of data type
osmesa.c:431: warning: comparison is always false due to limited range of data type
osmesa.c:437: warning: comparison is always false due to limited range of data type
osmesa.c:447: warning: comparison is always false due to limited range of data type
osmesa.c:453: warning: comparison is always false due to limited range of data type
osmesa.c:463: warning: comparison is always false due to limited range of data type
osmesa.c:466: warning: comparison is always false due to limited range of data type
osmesa.c:476: warning: comparison is always false due to limited range of data type
osmesa.c:479: warning: comparison is always false due to limited range of data type

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 136791ebc1fb91ef20dc65722a34f093d2947849)

vega: memset data array to zero to silence uninitialized var warnings
(cherry picked from commit 6386f80dbd6f1230abf16fa5ac65dc0dca70033a)

softpipe: move var initialization to silence warning
(cherry picked from commit 3e01c3f3baee82524e23107aecb2de4c7ee8b978)

softpipe: Silence unused variable warning on non-LLVM builds.

Fix this GCC warning with non-LLVM builds.
sp_screen.c: In function ‘softpipe_get_shader_param’:
sp_screen.c:141:28: warning: unused variable ‘sp_screen’ [-Wunused-variable]

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 8e543cc09862abb57e9d4dafe12e20a49972987b)

st/dri: Support 24bit formats in dri2_allocate_buffer

Prior commit 576161289df68eedade591fbca4013329c9e5ded,
the parameter format was bpp, thus both 24bit and 32bit formats were
requested with format set to 32. Handle 24bit seperately now.

Fixes RGBX formats in wayland platform for egl_dri2 (EGL_ALPHA_SIZE=0).

Note: This is a candidate for the 8.0 branch.
(cherry picked from commit c72d7df16879e3210946ba92a7edc823815b6f16)

st/xvmc: remove xorg-server dependency

Fixing a circular build dependency.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Christian König <deathsimple@vodafone.de>
(cherry picked from commit c2e2b58a58880c9b9f189fc154205e99144e9502)

mesa: Bump version number to 8.0-rc2

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

i965/vs: Use the sampler for VS pull constant loading on Ivybridge.

Substantially increases performance in GLBenchmark PRO:
- 320x240   => 3.28x
- 1920x1080 => 1.47x
- 2560x1440 => 1.27x

The LD message ignores the sampler unit index and SAMPLER_STATE pointer,
instead relying on hard-wired default state.  Thus, there's no need to
worry about running out of sampler units or providing SAMPLER_STATE;
this small patch should be all that's required.

NOTE: This is a candidate for release branches.
      (It requires the preceding commit to compile.)

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 259b65e2e7938de4aab323033cfe2b33369ddb07)

i965: Expose brw_set_sampler_message for use outside brw_eu_emit.c.

brw_SAMPLE is full of complex workarounds for original Broadwater
hardware, and I'd rather avoid all that for my next Ivybridge patch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 5f4575d42fdaaf671d4b3cdcf2c733ad9d35d339)

i965: Set pitch of pull constant buffers to 16.

We always access pull constant buffers using the message types "OWord
Block Read" or "OWord Dual Block Read".  According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:

    "the surface pitch is ignored, the surface is treated as a
    1-dimensional surface.  An element size (pitch) of 16 bytes is
    used to determine the size of the buffer for out-of-bounds
    checking if using the surface state model."

Previously we were setting the pitch for pull constant buffers to the
size of the whole constant buffer--this made no sense and would have
led to incorrect behavior if it were not for the fact that the pitch
is ignored.

For clarity, this patch sets the pitch for pull constant buffers to 16
bytes, consistent with the hardware's behavior.

v2: Clarify the meaning of the ignored values by writing them as (16 - 1).

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit fcd5af4a916b4ba7860ba27eb47404934bde0d08)

mesa: Don't resurrect deleted ARB VAOs in glPopClientAttrib

When ARB VAOs are used, glPopClientAttrib does not resurrect a deleted
VAO or VBO.  This difference between the two spec is, unfortunately,
not very well spelled out in the specs.

Fixes oglc vao(advanced.pushPop.deleteVAO) and
vao(advanced.pushPop.deleteVBO) tests.

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>
(cherry picked from commit 34c353ce463960afdf64fa2be1f155b8b7f6c70c)

mesa: Rename gl_array_object::VBOonly to ::ARBsemantics

There are more differences between Apple and ARB than just requiring
that all arrays be stored in VBOs.  Additional uses will be added in
following commits.

Also, set the flag at Bind time instead of Gen time.  The ARB_vao spec
specifies that behavior.

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>
(cherry picked from commit 09639901530da7df7347428512c2bee86af1ef8e)

swrast: Use fixed-function processing instead _TexEnvProgram for DrawPixels

This is a hack to work around drivers such as i965 that:

    - Set _MaintainTexEnvProgram to generate GLSL IR for
      fixed-function fragment processing.
    - Don't call _mesa_ir_link_shader to generate Mesa IR from the
      GLSL IR.
    - May use swrast to handle glDrawPixels.

Since _mesa_ir_link_shader is never called, there is no Mesa IR to
execute.  Instead do regular fixed-function processing.

Even on platforms that don't need this, the software fixed-function
code is much faster than the software shader code.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749
(cherry picked from commit 9be3be3c6654da18466626c2d45ff4d06b5fb953)

mesa: Make sure _TexEnvProgram points at the current ff fragment program

At least one place, the _mesa_need_secondary_color function in
state.h, uses this to make decisions.  The next patch in this series
will add another dependency.  Ideally, this field would go away and be
replace by a flag or something.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 34db7a8c1e775aaefad7952133e087f1c1a569f6)

swrast: fix uninitialized variable warning
(cherry picked from commit ba151a333be7a23266b23ee6f65669bb19221546)

swrast: make rowStride variable signed in put_z32_values()

As with commit aed5c8299fe47b8e1728f8140d069bc89d3fa947
(cherry picked from commit cf386f0a2ba3efcfd6ddbfcbebaf98a9bfa7a29f)

intel: use swrast code to map/unmap renderbuffers for swrast rendering
(cherry picked from commit 89bb19adb08caaefc01e613e9bbfbdd1f366ddab)

mesa: update comments, fix whitespace in dd.h
(cherry picked from commit 4baf90353dee771e553c552674616b93aedeaecf)

swrast: remove unused StoreTexel code

No longer needed since we do all rendering to texture with the buffer
mapping and pixel packing functions.
(cherry picked from commit 9403cc3aba0769dc6925cea3ec20aa95d491f516)

swrast: use Map/UnmapTextureImage() in framebuffer map/unmap code

When we're actually rendering into a texture, map the texture image
instead of the corresponding renderbuffer.  Before, we just copied
a pointer from the texture image to the renderbuffer.  This change
will make the code usable by hardware drivers.
(cherry picked from commit 1caf698191fb871850311353862eb7fc927f9f9c)

mesa: remove ctx->Driver.Map/UnmapTexture() hooks

No longer used anywhere.
(cherry picked from commit 56d83ac4bf0267982554f25c6fdb3c1dd6e14a9c)

nouveau: stop calling ctx->Driver.Map/UnmapTexture()

And remove unused nouveau_texture_map/unmap()
(cherry picked from commit 8b8a54afd9b748b7250993393864544ad6961edb)

tnl: remove ctx->Driver.Map/UnmapTexture() calls

ctx->Driver.MapTexture() always points to _swrast_map_texture().
We're already reaching into swrast from t_vb_program.c anyway.
This will let us remove the ctx->Driver.Map/UnmapTexture() functions.
(cherry picked from commit 4bbab2275f792553f8ed6bcebfe6acc4cb4179c2)

swrast: move some renderbuffer functions to s_renderbuffer.c
(cherry picked from commit bde356a1580f52cae0aaca020a33a6437083a450)

intel: remove intel_span_supports_format()

It always returned True.
(cherry picked from commit 1839a7fc9faae81d32ffc0cdc908b933f4524e28)

swrast: remove a few extra _mesa_get_format_bytes() calls
(cherry picked from commit 6c1e27ba219e41ae2641cca0d3c67462bdba8631)

mesa: update comments for gl_renderbuffer
(cherry picked from commit 1da7d6c919e9a6d756b208caa6685bfa1146b543)

mesa/swrast/drivers: remove obsolete gl_renderbuffer fields

This removes the last of the legacy fields from gl_renderbuffer.
(cherry picked from commit 1888dd52a32e114e7b3796db5a6b44921a2e04d4)

dri/swrast: use swrast_renderbuffer type
(cherry picked from commit becbb643135ddccac5054bf138ca0cc7cc3fff15)

swrast: use swrast_renderbuffer instead of gl_renderbuffer
(cherry picked from commit 0c1862851f27c428a18ba5509636efcc2f0084f8)

osmesa: use swrast_renderbuffer
(cherry picked from commit 797c18be1f907337ebd85b18ce43dfa0b056f492)

radeon: derive radeon_renderbuffer from swrast_renderbuffer
(cherry picked from commit c080202db5363a18a759a9a7c82b40ac558c8abe)

intel: derive intel_renderbuffer from swrast_renderbuffer

Drivers that rely on swrast need to do this, as with swrast_texture_image.
(cherry picked from commit 9f8ed9d66298e2dc5dff508e3ea723469fe06d93)

xlib: derive xmesa_renderbuffer from swrast_renderbuffer
(cherry picked from commit d16e71eeb47d1e67930f6e86a80dc926468224d9)

swrast: allocate swrast_renderbuffers instead of gl_renderbuffers
(cherry picked from commit f2479530b8be3866c234ac759a7fa84e634dd1aa)

swrast: new swrast_renderbuffer type

This will let us move the swrast-specific fields out of gl_renderbuffer.
(cherry picked from commit 34988272d9c7a889a26bb8bdcb841d44797a5dd6)

intel: use intel_rb_format() to get renderbuffer format

This will make future changes cleaner and less invasive.
(cherry picked from commit 924de7dc96f4607cb3d833637b5f69f4b9e2a6d0)

dri/swrast: rename swrast_renderbuffer to dri_swrast_renderbuffer

To prevent name collision with future swrast_renderbuffer in the swrast
module.
(cherry picked from commit 1048d55d5fa60d17dd99ac7394ff0572500625f9)

swrast: use stencil packing function in s_stencil.c
(cherry picked from commit c45771905f237d9285465dfce955440582ee51e5)

swrast: use color packing functions in s_span.c
(cherry picked from commit 881ef2a9db22cff4c7d07b873d23b0c324da555a)

swrast: remove s_spantemp.h
(cherry picked from commit 8696a5210289166ce39d765d771258258400e876)

xlib: remove xm_span.c and related code
(cherry picked from commit b0f0d7a8118401b209c674804255b5fd9e8c94c0)

mesa: remove gl_renderbuffer::Wrapped

There's no such thing as renderbuffer wrappers anymore.
(cherry picked from commit 59a5b5a193d5d9c5776aa586b34657b6e315479d)

swrast: rewrite, simplify the the render-to-texture code
(cherry picked from commit ab331140c68d1c157e69ea8e53b44729355fa43c)

mesa: rename gl_renderbuffer::Data to Buffer

To better indicate that this pointer to the malloc'd memory.
(cherry picked from commit 7a36345f70a0b8ac2d480bb52eb2c74c2be5a978)

mesa: move freeing of software renderbuffers into swrast
(cherry picked from commit f6a3979a0444a14c198c10501e9ff13f24625443)

mesa: remove gl_renderbuffer::DataType
(cherry picked from commit f9874feef4d8952df5054bd8e8f4e0deda4ef44f)

mesa: remove gl_renderbuffer:RowStride field
(cherry picked from commit 1e1b5cb01a10e39d01923e3c7e989c44210950cd)

mesa: finally, remove the GetRow/PutRow/etc functions
(cherry picked from commit 82846fea4d042466ccfd5b3c86d98e856086cc05)

dri: remove all the obsolete spantmp files
(cherry picked from commit 304f7a132741a528ca6e861a918ef59991874e5f)

radeon: remove obsolete GetRow/PutRow code
(cherry picked from commit a4c6dedb27897ae1340983b5d12927e0a9fb2212)

nouveau: remove obsolete GetRow/PutRow code
(cherry picked from commit f892debdc21d12c40d2b69b4e9efdf527672d3ec)

intel: remove most of the span Get/PutRow code
(cherry picked from commit 41869c49421141807ab71cabca4c8a07611f6a64)

dri/swrast: remove obsolete GetRow/PutRow code

This is a squash of:

    dri/swrast: remove obsolete GetRow/PutRow code
    (cherry picked from commit cb5fa9ea624574909bf57f9e1ad190a440d59dc2)

and

    dri/swrast: remove obsolete swrast_span.c file from source list
    (cherry picked from commit a9bf149e7f699d05bcf31dff54c4b4cf78018dd0)

    Conflicts:

src/mesa/drivers/dri/swrast/Makefile.sources

osmesa: remove obsolete GetRow/PutRow code
(cherry picked from commit 2873555a76a7358db053c3a7b121b489f8df9bb1)

xlib: remove obsolete GetRow/PutRow code
(cherry picked from commit 2e80c7e5bf822e3b9efd145d33badcf4f14504ff)

mesa: remove obsolete PutRow, etc assignments
(cherry picked from commit 0d2f0c8bb86b8dfcb6f0be7bf027fe725007bc5f)

swrast: remove Get/PutRow()-related code
(cherry picked from commit d65bbfa947b9e2c5353bda857470a01d5398b3fa)

st/mesa: remove gl_renderbuffer::GetPointer stuff
(cherry picked from commit a4a566a610778e6ab93424a38e372c3dcb7d92d3)

swrast: stop using Put/GetRow/Values() in swrast code

All color buffer rendering is now done by accessing mapped renderbuffer
memory.  We're now able to get rid of all the GetRow/PutRow stuff.
(cherry picked from commit 0ff817f200ef4cb4a5ab0d90eccfc83d0671fb65)

swrast: use gl_renderbuffer::StrideInBytes in depth/stencil code
(cherry picked from commit b766d4bb43b2c8271413c1efafe3590fa75efc3c)

mesa: use gl_renderbuffer::Map for all depth/stencil accesses

Instead of using the obsolete gl_renderbuffer::Data field.
Color buffer are still accessed through GetRow/PutRow().
(cherry picked from commit 7d1ddec92168e9b6ead0da80b18364a75f9a85e6)

intel: make intel_renderbuffer_map/unmap() static
(cherry picked from commit 14da67d9b9b9e30740ef1687c3952a0b5e8b0a54)

mesa: add new gl_renderbuffer fields

These are temporary, actually, but they'll make follow-on work easier to
implement in a step-by-step manner.  Eventually the Map and RowStrideBytes
fields will go into a new swrast_renderbuffer type, but adding that type
now would involve touching a _lot_ of code that'll eventually be removed.

The fields marked as obsolete will go away completely at some point.
(cherry picked from commit 827c1d66f671e50d9d96277b1fd3a59309626f66)

swrast: flush pending rendering before unmapping buffers
(cherry picked from commit fc9f74839d50ab5480ae657524cf2ddebf55d451)