ilo: introduce blend CSO

Introduce ilo_blend_cso and initialize it in create_blend_state().  This saves
us from having to construct hardware blend states in draw_vbo().

ilo: introduce sampler CSO

Introduce ilo_sampler_cso and initialize it in create_sampler_state().  This
saves us from having to perform CPU-intensive calculations to construct
hardware sampler states in draw_vbo().

ilo: construct SCISSOR_RECT in set_scissor_states()

This allows us to memcpy() the state in draw_vbo().  Add ilo_init_states() and
ilo_cleanup_states() that are called when contexts are created and destroyed
respectively, and properly set the initial scissor state in ilo_init_states().

ilo: introduce viewport CSO

Introduce ilo_viewport_cso and initialize it in set_viewport_states().  This
saves us from having to perform CPU-intensive calculations to construct
hardware viewport states in draw_vbo().

ilo: switch to ilo states for shaders and resources

Define and use

 struct ilo_sampler_state;
 struct ilo_view_state;
 struct ilo_cbuf_state;
 struct ilo_resource_state;
 struct ilo_global_binding;

in ilo_context.

ilo: switch to ilo states for CC stage

Define and use

 struct ilo_dsa_state;
 struct ilo_blend_state;
 struct ilo_fb_state;

in ilo_context.

ilo: switch to ilo states for WM stage

Define and use

 struct ilo_rasterizer_state;

in ilo_context.

ilo: switch to ilo states for CLIP and SF stages

Define and use

 struct ilo_viewport_state;
 struct ilo_scissor_state;

in ilo_context.

ilo: switch to ilo states for SOL stage

Define and use

 struct ilo_so_state;

in ilo_context.

ilo: switch to ilo states for VF stage

Define and use

 struct ilo_vb_state;
 struct ilo_ve_state;
 struct ilo_ib_state;

in ilo_context.

ilo: move hardware limits to ilo_gpe.h

draw: trivial fix comment typo

gallium/tgsi: add missing string for layer semantic

Also report if a shader writes the layer semantic

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

llvmpipe: bump 3d and cube map limits to 2048 and 8192 respectively

These should just work, required by d3d10. Too large resources will
get thrown out separately anyway.

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

glsl: Fix uniform buffer object counting.

We were counting uniforms located in UBOs against the default uniform
block limit, while not doing any counting against the specific combined
limit.

Note that I couldn't quite find justification for the way I did this, but
I think it's the only sensible thing: The spec talks about components, so
each "float" in a std140 block would count as 1 component and a "vec4"
would count as 4, though they occupy the same amount of space.  Since GPU
limits on uniform buffer loads are surely going to be about the size of
the blocks, I just counted them that way.

Fixes link failures in piglit
arb_uniform_buffer_object/maxuniformblocksize when ported to geometry
shaders on Paul's GS branch, since in that case the max block size is
bigger than the default uniform block component limit.

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

glsl: Make a local variable to avoid restating this array lookup.

v2: Convert another instance of the array lookup. (caught by Tapani)

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

intel: Use the CHIPSET macro in the PCI ID tables for the device name.

Putting the human readable device names directly in the PCI ID list
consolidates things in one place.  It also makes it easy to customize
the name on a per-PCI ID basis without a huge code explosion.

Based on a patch by Kristian Høgsberg.

v2: Fix 830M/845G names and #undef CHIPSET (caught by Emit Velikov).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

intel: Remove 'misc' parameter from CHIPSET macro in PCI ID tables.

This has never actually been used for anything.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

build: Use PACKAGE_VERSION from autoconf

Both variables had the same value.

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

build: Unify PACKAGE_VERSION on autotools, scons and Android

This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.

Current behaviour is:
 - Autotools uses 9.2.0 as PACKAGE_VERSION
 - Scons and Android use 9.2-devel as PACKAGE_VERSION

With this patch all three build systems use 9.2.0-devel as
PACKAGE_VERSION.

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

radeon/winsys: correct RADEON_GEM_WAIT_IDLE use

RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.

Problem originally noticed in libdrm by Mark Kettenis.
Dave Airlie pointed out that mesa has the same issue.

Signed-off-by: Jonathan Gray <jsg@jsg.id.au>

configure.ac: Build dricommon for gallium swrast

When building dri-swrast, use gallium_check_st to set HAVE_COMMON_DRI.
Commit 07f2dee7 added setting of HAVE_COMMON_DRI in gallium_check_st.
But the dri-swrast case did not use gallium_check_st.
So dri/common was still not built.

v2: set HAVE_COMMON_DRI=yes instead of using gallium_check_st

NOTE: This is a candidate for the 9.1 branch.
      (Depends on 7de78ce5 and 07f2dee)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61821
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>

i965: Adding more reserved PCI IDs for Haswell.

At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.

NOTE: This is a candidate for stable branches.

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>

mesa: remove outdated version lines in comments

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

gallium: System z support

The main change is to use MCJIT rather than the old JIT, which will never
be supported for System z.  The endianness part is by example since the
patch was tested on a glibc system.

Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Signed-off-by: Brian Paul <brianp@vmware.com>

llvmpipe: improve alignment calculation for fetching/storing pixels

This was always doing per-pixel alignment which isn't necessary, except
for the buffer case (due to the per-element offset). The disabled code
for calculating it was incorrect because it assumed that always the full
block would be fetched, which may not be the case, so fix this up.
The original code failed for instance for r10g10b10a2 the alignment would
have been calculated as 4 (block_width) * 4 (bytes) so 16, but the actual
fetch may have only fetched 2 values at a time, hence only alignment 8 -
it is unclear what exactly would happen in this case (alignment larger
than size to fetch).
So just use the (already calculated) fetch size instead and get alignment
from that which should always work, no matter if fetching 1,2 or 4 pixels.

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

llvmpipe: reduce alignment requirement for 1d resources from 4x4 to 4x1

For rendering to buffers, we cannot have any y alignment.
So make sure that tile clear commands only clear up to the fb width/height,
not more (do this for all resources actually as clearing more seems
pointless for other resources too). For the jit fs function, skip execution
of the lower half of the fragment shader for the 4x4 stamp completely,
for depth/stencil only load/store the values from the first row
(replace other row with undef).
For the blend function, also only load half the values from fs output,
replace the rest with undefs so that everything still operates on the
full 4x4 block to keep code the same between 4x1 and 4x4 (except for
load/store of course which also needs to skip (store) or replace these
values with undefs (load))., at the cost of slightly less optimal code
being produced in some cases.
Also reduce 1d and 1d array alignment too, because they can be handled the
same as buffers so don't need to waste memory.

v2: don't try to run special blend code for 4x1, (very) slightly less
complexity if we just use the same code as for 4x4 which may or may not
make it easier to optimize in the future (as we care a lot more about 4x4
performance than 1d).

v2: don't use undef values for unused fs src outputs with llvm 3.1 as it
apparently can trigger a bug in llvm.

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

llvmpipe: cleanup of generate_unswizzled_blend

Some parameters were used inconsistently, for instance not using
block_width/block_height/block_size for deferring number of pixels
but rather relying on guesses from the number of fragment shaders etc,
so fix this up (no actual change in behavior since the block size stays
fixed). (Though most of the code would work with different block_height,
with three exceptions, one being the hacked r11g11b10 conversions and
twiddle code which only work with block_height 2 not 1, and the last
one being blend vector type not being 128bit wide.)

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

gallivm: enhance special sse2 4x4f and 2x8f -> 1x16ub conversion

There's no good reason why it can't handle 2x4f->1x8ub, 1x4f->1x4ub and
1x8f->1x8ub cases, there might be legitimate reasons why we don't have
enough input vectors for a full destination vector, and using pack
intrinsics should still be much better than using generic conversion
(it looks like convert_alpha from the blend code might hit this though
I suspect it could be avoided).

v2: add another test vector format to lp_test_conv so this gets tested.

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

gallivm: (trivial) fix lp_build_concat_n

The code was designed to handle no-op concat but failed (unless the
caller was using same pointer for src and dst).

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

mesa: change MAX_PROGRAM_ADDRESS_REGS to 1, clamp to it in state tracker

We've never properly supported more than one address register.  There
isn't even a field in prog_src_register or prog_dst_register to indicate
which address register to use if RelAddr!=0.

In the state tracker, clamp MaxAddressRegs against MAX_PROGRAM_ADDRESS_REGS
since many gallium drivers do support more.

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

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

intel: Don't try to blorp or blit CopyTexSubImage(1D_ARRAY).

Blorp and the hardware blitter can't be used to implement
CopyTexSubImage when the image type is 1D_ARRAY, because of a
coordinate system mismatch (the Y coordinate in the source image is
supposed to be matched up to the Z coordinate in the destination
texture).

The hardware blitter path (intel_copy_texsubimage) contained a perf
debug warning for this case, but it failed to actually fall back.  The
blorp path didn't even check.

Fixes piglit test "copyteximage 1D_ARRAY".

Reviewed-by: Eric Anholt <eric@anholt.net>

i965/gen6+: Fix multisample assertions in CopyTexSubImage hw blitter path.

Commit 045612c (intel: Add an assert for glCopyTexSubImage() being
called on MSAA buffers) added an assertion to intel_copy_texsubimage()
to make sure that multisampling was not in use, based on the
assumption that glCopyTexSubImage() can't legally be used with
multisampling.

However, there is one case where glCopyTexSubImage() can legally be
used with multisampling: when the source buffer is a multisampled
window system buffer.  If the source and destination color formats
don't match, the blorp path will fail, so intel_copy_texsubimage()
will be called.  In this case, we need intel_copy_texsubimage() to
return false so that we fall back to meta to do the copy.  (The
multisampled source buffer won't cause a problem for the meta path,
because it uses glReadPixels, which forces a multisample resolve).

It's still safe to assert that the destination image is
single-sampled, because it's not legal to call glCopyTexSubImage() on
multisampled textures.

Fixes some failures with piglit tests "copyteximage
{1D,2D,CUBE,RECT,2D_ARRAY}" (with "samples=..." argument).

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: Prevent possible out-of-bounds read by save_SamplerParameterfv.

Fixes "Out-of-bounds access" defect reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

i965: fix problem with constant out of bounds access (v3)

Okay I now understand why Frank would want to run away, this is
my attempt at fixing the CVE out of bounds access to constants
outside the range. This attempt converts any illegal constants
to constant 0 as per the GL spec, and is undefined behaviour.

A future patch should add some debug for users to find this out,
but this needs to be backported to stable branches.

CVE-2013-1872

v2: drop the last hunk which was a separate fix (now in master).
hopefully fix the indentations.

v3: don't fail piglit, the whole 8/16 dispatch stuff was over
my head, and I spent a while figuring it out, but this one is
definitely safe, one piglit pass extra on my Ironlake.

NOTE: This is a candidate for stable branches.

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

intel: Fix copying of separate stencil data in glCopyTexSubImage().

We were copying the source stencil data onto the destination depth data.

Fixes piglit copyteximage other than 1D_ARRAY.

v2: Fix unintentional dropping of the "don't double-copy for packed
    depth/stencil" check.  While blorp is only supported on separate
    stencil hardware at the moment, hopefully that will change soon.
    Review by Jordan.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

meta: Fix temporary image type for float depth/stencil.

Fixes assertion failure in piglit copyteximage.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

intel: Fix performance regression from miptree blit changes.

When making v2 of da2880bea05bfc87109477ab026a7f5401fc8f0c, I carefully
checked all of the calls in that commit to see that I'd updated them, but
forgot to update the new calls in the later commits such as
.e845c5cf7abce55759501a473459aff3bf25c9ca.  As a result, we were getting Y
tiled temporaries even though the whole point of the temporary was to
untile!

The steady state of the intro scene of lightsmark goes from 13 to 17 fps.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65154
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

glcpp: Add test case for recently fixed loop-control underflow bug.

To trigger the bug, it suffices to have a line-continuation followed by
a newline and then a non-line-continuation backslash.

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

glcpp: Fix post-decrement underflow in loop-control variable

This loop-control condition with a post-decrement operator would lead to
an underflow of collapsed_newlines. This in turn would cause a subsequent
execution of the loop to labor inordinately trying to return the loop-control
variable to a value of 0 again.

Fix this by dis-intertwining the test and the decrement.

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

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

i965: Fix glColorPointer(GL_FIXED)

When a gl_client_array is created with glColorPointer,
gl_client_array::Normalized is true. This caused the translation from the
gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail.

Fixes the spinning cube's color in Android 4.2's ApiDemos.apk,
"Graphics > OpenGL ES".

Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell
and Ivybridge:
  brw_draw_upload.c:287: get_surface_type: Assertion `0' failed.

No Piglit regressions on Haswell.

Note: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42182
Issue: AXIA-2954
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

softpipe: draw_find_shader_output returns -1 on invalid outputs

It was changed from 0 to allow shader outputs at 0 that are
different from position.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

radeonsi/compute: Upload work group, work item size in input buffer

radeonsi/compute: Pass kernel arguments in a buffer v2

v2:
  - Fix memory leak in si_set_constant_buffer()

radeonsi/compute: Implement un-binding of global buffers

radeonsi/compute: Support multiple kernels in a compute program

radeonsi/compute: Add missing PIPE_COMPUTE caps

i965 gen7: use SURFACE_STATE fields to select render level/layer

Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa/texformat: add _mesa_tex_target_is_array function

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

intel: add layered parameter to update_renderbuffer_surface

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

intel_fbo: set gl_renderbuffer Depth field

Set the renderbuffer's Depth field to match the texture's
Depth when rendering to a texture.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

intel: print image depth in debug message

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: handle missing read buffer in _mesa_get_color_read_format/type()

We were crashing when GL_READ_BUFFER == GL_NONE.  Check for NULL
pointers and reorganize the code.  The spec doesn't say which error
to generate in this situation, but NVIDIA raises GL_INVALID_OPERATION.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65173
NOTE: This is a candidate for the stable branches.

Tested-by: Vedran Rodic <vrodic@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>

meta: move vertex array enables for mipmap generation

Before, on the second call to GenerateMipmap we were enabling two
vertex arrays for the current vertex array object, rather than
the private generate-mipmap vertex array object.  This caused
things to blow up elsewhere.

This patch moves the array enables into the block where the
generate-mipmap vertex array object is created, as we do in
the setup_ff_generate_mipmap() function.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60518
NOTE: This is a candidate for the stable branches.

Tested-by: core13@gmx.net
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: fix hodge podge indentation, update comments in texformat.c

gallium: add support for layered rendering

Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER).
(Note that what GL knows as "gl_Layer" variable d3d10 is naming
"RENDER_TARGET_ARRAY_INDEX".)

v2: drop cap bit (just tied to geometry shader), add docs.

gallivm: fix out-of-bounds access with mirror_clamp_to_edge address mode

Surprising this bug survived so long, we were missing a clamp (in the
linear filtering version).
(Valgrind complained a lot about invalid reads with piglit texwrap,
I've also seen spurios failures in this test which might have
happened due to this. Valgrind probably didn't complain before the
alignment reduction in llvmpipe to 4x4 since the test is using tiny
textures so the reads were still always well within allocated area.)
While here, also do an effective clamp (after half subtraction)
of [0,length-0.5] instead of [0, length-1] which saves an instruction
(the filtering weight could be different due to this, but only if
both texels point to the same max texel so it doesn't matter).
(Both changes are borrowed from PIPE_TEX_CLAMP_TO_EDGE case.)

Note: This is a candidate for the stable branches.

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

llvmpipe: fix bogus assertions for buffer surfaces

One of the assertion made no sense for buffer rendertargets
(due to the union), so drop it. (The same assertion is present already in
the path for texture surfaces later.).

v2: make assertion completely accurate (suggested by Jose).

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

i965: Fix haswell_upload_cut_index when there's no index buffer.

brw->ib.type is reset to -1 at the start of each batch.  If there's no
index buffer, it won't get updated to a sensible value, resulting in
_mesa_primitive_restart_index's "Invalid index buffer type" assertion
tripping.

Fixes a regression since 7c87a3b5dac118697a9b67caa7b6d5cab60f316d.

NOTE: This is a candidate for the 9.1 branch (and should be squashed).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65195
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

llvmpipe: reduce alignment requirement for resources from 64x64 to 4x4

The overallocation was very bad especially for things like 1d array
textures which got blown up by a factor of 64. (Even ordinary smallish
2d textures benefit a lot from this, a mipmapped 64x64 rgba8 texture
previously used 7*16kB = 112kB instead of now ~22kB.)
4x4 is chosen because this is the size the jit functions run on, so
making it smaller is going to be a bit more complicated.
It is actually not strictly 4x4 pixel, since we'd want to avoid situations
where different threads are rendering to the same cacheline so we keep
cacheline size alignment in x direction (often 64bytes).
To make this work introduce new task width/height parameters and make
sure clears don't clear the whole tile if it's a partial tile. Likewise,
the rasterizer may produce fragments outside the 4x4 blocks present in a
tile, so don't call the jit function for them.
This does not yet fix rendering to buffers (which cannot have any y
alignment at all), and 1d/1d array textures are still overallocated by a
factor of 4.

v2: replace magic number 4 with LP_RASTER_BLOCK_SIZE, fix size of buffers
allocated (needed in case we render to them).

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

llvmpipe: Remove x/y from cmd_bin

These were mostly just a waste of memory and cache pressure, and were
really only used for debugging.

This change reduces instruction count (as measured by callgrind's Ir
event) of gnome-shell-perf-tool on Ivybridge by 3.5% ± 0.015% (n=20).

Signed-off-by: Adam Jackson <ajax@redhat.com>

r600g/sb: fix broken assert

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

glapi: Add some missing static_dispatch="false" annotations to es_EXT.xml

This fixes the following build errors on powerpc:

  CC     glapi_dispatch.lo
  In file included from glapi_dispatch.c:90:0:
  ../../../../../src/mapi/glapi/glapitemp.h:1640:1: error: no previous
  prototype for 'glReadBufferNV' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:4198:1: error: no previous
  prototype for 'glDrawBuffersNV' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6377:1: error: no previous
  prototype for 'glFlushMappedBufferRangeEXT'
  [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6389:1: error: no previous
  prototype for 'glMapBufferRangeEXT' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6401:1: error: no previous
  prototype for 'glBindVertexArrayOES' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6413:1: error: no previous
  prototype for 'glDeleteVertexArraysOES' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6433:1: error: no previous
  prototype for 'glGenVertexArraysOES' [-Werror=missing-prototypes]
  ../../../../../src/mapi/glapi/glapitemp.h:6445:1: error: no previous
  prototype for 'glIsVertexArrayOES' [-Werror=missing-prototypes]

NOTE: This is a candidate for the 9.0 and 9.1 branches.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

mesa: Add missing break statement in _mesa_choose_tex_format.

Fixes "Missing break in switch" defect reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

integer overflow in XF86DRIGetClientDriverName() [CVE-2013-1993 2/2]

clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.

NOTE: This is a candidate for stable release branches.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

integer overflow in XF86DRIOpenConnection() [CVE-2013-1993 1/2]

busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.

NOTE: This is a candidate for stable release branches.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

mesa: fix error checking of DXT sRGB formats in _mesa_base_tex_format()

For formats such as GL_COMPRESSED_SRGB_S3TC_DXT1_EXT we need to
have both the GL_EXT_texture_sRGB and GL_EXT_texture_compression_s3tc
extensions.  This patch adds the missing check for the later.

Found when checking out https://bugs.freedesktop.org/show_bug.cgi?id=65173

NOTE: This is a candidate for the stable branches.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: asst. whitespace, formatting fixes in teximage.c

draw: fix vs/fs input/output mismatches

When we've changed draw_find_shader_output to return -1 instead
of 0 on non found attribs we broke the default behavior of
draw, which was to always redirect those to the first (0th) slot.
To preserve that behavior if draw_emit_vertex_attr notices a
mismatched vertex attrib, it just redirects it to the first slot
(instead of trying to use negative index in an array).

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>

intel: Add multisample scaled blitting in blorp engine

In traditional multisampled framebuffer rendering, color samples must be
explicitly resolved via BlitFramebuffer before doing the scaled blitting
of the framebuffer. So, scaled blitting of a multisample framebuffer
takes two separate calls to BlitFramebuffer.

This patch implements the functionality of doing multisampled scaled
resolve using just one BlitFramebuffer call. Important changes involved
in this patch are listed below:
    - Use float registers to scale and offset texture coordinates.
    - Change offset computation to consider float coordinates.
    - Round the scaled coordinates down to nearest integer.
    - Modify src texture coordinates clipping to account for scaling..
    - Linear filter is not yet implemented in blorp. So, don't use
      blorp engine to do single sampled scaled blitting.

V3: Fix nearest filtering issue in scaled blits. Makes failing piglit
fbo-blit-stetch test and framebuffer_blit_functionality_magnifying_blit.test
in gles3 CTS pass.

Observed no piglit, gles3 CTS regressions on sandybridge & ivybridge with
this patch.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

intel: Change the register type from UW to UD in blorp engine

These changes are required to implement scaled blitting in blorp
in my next patch.

No regressions observed in piglit quick-driver.tests with this patch.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

mesa: Implement ext_framebuffer_multisample_blit_scaled extension

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Revert "i965: fix problem with constant out of bounds access (v2)"

This reverts commit 98dfd59a0445666060c97b0dccaf0e9f030b547a.

The patch was clearly not Piglit tested, as it caused at least 225
tests to start crashing with assertion failures.  That was before my
desktop tanked and the test run died completely.

ilo: simplify shader variant handling

Remove hash function on shader variants. Nature of variants limits them to a
small number and thus its more efficient to just do a memory compare of the
actual shader structures rather than compute and compare hashes.

i965: fix problem with constant out of bounds access (v2)

This is my attempt at fixing this as the CVE is making RH security team
care enough to make me look at this. (please upstream, security fixes are
more important than whatever else you are doing, if for no other reason than
it saves me having to fix stuff I've no real clue about).

Since Frank's original fix was denied, here is my attempt to just
alias all constants that are out of bounds < 0 or > nr_params to constant 0,
hopefully this provides the undefined behaviour idr requires..

CVE-2013-1872

v2: drop the last hunk which was a separate fix (now in master).
hopefully fix the indentations.

NOTE: This is a candidate for stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

intel: initialize fs_visitor::params_remap in constructor

Set fs_visitor::params_remap to NULL in the constructor.
This variable was potentially tested in fs_visitor::remove_dead_constants()
before being set.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Frank Henigman <fjhenigman@google.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

draw: add cast in debug_printf() to silence warning

svga: add PIPE_CAP_MAX_VIEWPORTS to switch to silence warning

draw: make sure viewport index is fetched from leading vertex

Viewport index should only be used on a per primitive basis, so
instead of fetching it from each vertex, potentially making each
vertex in a primitive use a different viewport index, which is
obviously broken, make sure that we only fetch from the first
vertex in the primitive making the viewport index the same
for the entire primtive.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

llvmpipe: clamp scissors to be between 0 and max

We need to clamp to make sure invalid shader doesn't crash our
driver. The spec says to return 0-th index for everything that's
out of bounds.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

draw: clamp the viewports to always be between 0 and max

If the viewport index is larger than the PIPE_MAX_VIEWPORTS,
then the first (0-th) viewport should be used.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

gallium/docs: adds documentation for multi viewport cap

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

draw: fixup draw_find_shader_output

draw_find_shader_output like most of the code in draw used to
depend on position always being at output slot 0. which meant
that any other attribute being at 0 could signify an error.
unfortunately position can be at any of the output slots, thus
other attributes can occupy slot 0 and we need to mark the ones
which were not found by something else. This commit changes
draw_find_shader_output so that it returns -1 if it can't
find the given attribute and adjust the code that depended
on it returning >0 whenever it correctly found an attrib.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

llvmpipe: implement support for multiple viewports

Largely related to making sure the rasterizer can correctly
pick out the correct scissor box for the current viewport.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

draw: implement support for multiple viewports

This adds support for multiple viewports to the draw module.
Multiple viewports depend on the presence of geometry shaders
which can write the viewport index.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

gallium: Add support for multiple viewports

Gallium supported only a single viewport/scissor combination. This
commit changes the interface to allow us to add support for multiple
viewports/scissors.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

mesa: Delete the ctx->Array._RestartIndex derived state.

It's incorrect and isn't used any longer.

v2: Actually flush vertices/flag _NEW_TRANSFORM on RestartIndex change.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Ignore fixed-index primitive restart in ArrayElement().

GL_PRIMITIVE_RESTART_FIXED_INDEX is only supposed to apply to
glDrawElements*.  This code is for legacy drawing paths and display
lists, so it shouldn't apply.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

st/mesa: Go back to using ctx->Array.RestartIndex, not _RestartIndex.

The derived _RestartIndex field is an attempt to support both
GL_PRIMITIVE_RESTART and GL_PRIMITIVE_RESTART_FIXED_INDEX (part of ES
3.0).  Gallium drivers don't appear to support ES 3.0 yet, so they don't
need to use it.  Plus, it's broken and going to go away soon.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Fix can_cut_index_handle_restart_index() for byte/short types.

Pre-Haswell hardware doesn't support an arbitrary restart index, and
instead compares the index buffer value against 0xFF for byte-size
buffers, 0xFFFF for short-size buffers, or 0xFFFFFFFF for unsigned
integer buffers.

OpenGL allows the restart index to be an arbitrary unsigned integer.
When comparing against byte/short types, the index buffer value should
be promoted to a full 32-bit integer before doing the comparison.  The
restart index is /not/ supposed to be masked to byte/short size.

This means that with certain restart indexes, the comparison should
always fail.  For example, a restart index of 0xF000FFFF should never
match any byte/short index buffer values due to the extra high bits.

We must not enable hardware primitive restart in such a case.  For now,
fall back to software primitive restart as it's the simplest fix.  In
the future, we could detect restart indexes that will never match and
skip both hardware and software primitive restart.

NOTE: This is a candidate for stable branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Use the correct restart index for fixed index mode on Haswell.

The code that updates the ctx->Array._RestartIndex derived state mashed
it to 0xFFFFFFFF when GL_PRIMITIVE_RESTART_FIXED_INDEX was enabled
regardless of the index buffer type.  It's supposed to be 0xFF for byte,
0xFFFF for short, or 0xFFFFFFFF for integer types.

The new _mesa_primitive_restart_index() helper gets this right.

The hardware appears to compare against the full 32-bit value some of
the time, causing primitive restart not to occur when it should.  The
fact that it works some of the time is rather frightening.

Fixes sporadic failures in the ES 3 instanced_arrays_primitive_restart
conformance test when run in combination with other tests.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

vbo: Use the new primitive restart index helper function.

This gets the correct restart index for unsigned byte/short types when
using GL_PRIMITIVE_RESTART_FIXED_INDEX.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Add a helper function for determining the restart index.

The derived state approach currently used (_RestartIndex) doesn't work:
in the GL_PRIMITIVE_RESTART_FIXED_INDEX case, the restart index depends
on the index buffer's data type, and that isn't known until draw time.

The existing code also fails to obey the GL 4.3 rules which say that
FIXED_INDEX takes precedence over normal primitive restart.

This helper function correctly determines the restart index, and will
replace the derived state.

NOTE: This is a candidate for the 9.1 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

vbo: Ignore PRIMITIVE_RESTART_FIXED_INDEX for glDrawArrays().

The derived _PrimitiveRestart enable flag combines the PrimitiveRestart
and PrimitiveRestartFixedIndex enable flags.  However, DrawArrays is not
supposed to do FixedIndex restart:

From the OpenGL 4.3 Core specification, section 10.3.5 (page 302):
"If PRIMITIVE_RESTART_FIXED_INDEX is enabled, primitive restart is not
 performed for array elements transferred by any drawing command not
 taking a type parameter, including all of the *Draw* commands other
 than *DrawElements*."

The OpenGL ES 3.0 specification agrees by omission:
"When DrawElements, DrawElementsInstanced, or DrawRangeElements
 transfers a set of generic attribute array elements to the GL..."

Notably, DrawArrays is not included in the list of draw calls that
take PRIMITIVE_RESTART_FIXED_INDEX into consideration.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965/vs: Fix implied_mrf_writes() for integer division pre-gen6.

Previously it would assertion fail in debug builds (though the correct
value was returned in a non-debug build).  Marking it as a candidate for
stable even though it has no current consumers in the stable branches, in
case one shows up in a later backport.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64727
NOTE: This is a candidate for stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Fix test for smearing enabled on an instruction.

We were expanding the live range too far, breaking register_coalesce_2()
and compute_to_mrf() on 16-wide shaders.  Turning it back on improves
GLB2.7 performance by 0.239355% +/- 0.0850649% (n=398). shader-db stats
are:

total instructions in shared programs: 1627211 -> 1609262 (-1.10%)
instructions in affected programs:     450351 -> 432402 (-3.99%)

While 33 new 16-wide shaders are gained, 70 are lost.  Despite that,
tropics (the app that lost the most 16-wide) shows a .41% +/- .16%
(n=7/8, first-run outlier removed) performance improvement on my HSW.

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

i965/fs: Fix segfault in instruction scheduling with LINTERP using last GRF.

The scheduler didn't know about uniform-type accesses, and if a uniform
access was last in a 16-wide, we'd walk off the end of the array.  This
never happened, because we'd never coalesce out all the GRFs, due to a bug
to be fixed in the next commit.

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

mesa: Fix test for optimistic coloring being necessary.

i965 and radeon use ra_set_node_reg() to force payload registers to
specific registers while exposing those registers to the allocator still.
We were treating those register nodes as unsuccessfully allocated in the
ra_simplify() step, leading to walking the registers again to do
optimistic coloring even if there was nothing left ot do.

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

gallium: fix build on uclibc system

execinfo.h and debug_symbol_name_glibc() are pure GNU-isms and do not
build on uclibc systems.  A previous patch addressed this issue, but
there was an error.  This patch corrects that error.  See

  https://bugs.freedesktop.org/show_bug.cgi?id=51782
  https://bugs.gentoo.org/show_bug.cgi?id=469768

Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
Signed-off-by: Brian Paul <brianp@vmware.com>

intel: Enable blit glCopyTexSubImage/glBlitFramebuffer with sRGB.

Since the introduction of default-to-SARGB8 window system framebuffers,
non-blorp hardware lost blit acceleration for these two paths between the
window system and ARGB8888 textures.  Since we shouldn't be doing any
conversion anyway, just compatibility-check the linear variants of the
formats.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61954
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>