Assigning a struct only copies the members - any padding is left as is.
Thus this code:
struct foo_t foo;
foo = bar;
leaves the padding of foo intact, ie uninitialized random garbage.
This patch fixes constant shader recompiles by initializing the struct
to zero. For completeness, memcpy is used to copy the key to the shader
struct.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
(cherry picked from commit e495d88453)
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>
(cherry picked from commit 962204961d)
Commit 67ef7559 added an || test "x$enable_dri" check in an attempt to
get the DRI common bits built in some necessary cases. That change was
inappropriate as it made these common DRI pieces be built
unconditionally, so some builds were broken.
Subsequently, commit 998d975e3 change the "|| test" to a "-a"
conjunction within the existing test invocation. This made the '-a
"x$enable_dri" = xyes' clause have no effect, (as it was inside an
enclosing test for the same condition). So the new breakage from
commit 67ef7559 was addressed, but the original problems were
regressed.
The immediately preceding commit removed the redundant condition.
Now, finally this commit fixes the original problem as described in
the commit message of 67ef7559: this code should be compiled when
using the DRI state tracker. In order to do so, the HAVE_*_DRI
conditionals must be moved after the last assignment of HAVE_COMMON_DRI.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61821
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit 07f2dee731)
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>
(cherry picked from commit 5ea43e6549)
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>
(cherry picked from commit 51498a3e71)
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>
(cherry picked from commit 02fe736cc0)
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>
(cherry picked from commit e6efb900e7)
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>
(cherry picked from commit 51c0ffacb2)
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>
(cherry picked from commit a41478e3f6)
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>
(cherry picked from commit 49aba27973)
The original commit introduced a regression which was fixed in this one,
so I just picked both and squashed them together. Since no patch landed
with this name, it still showed up in the list.
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.
(cherry picked from commit 7c87a3b5da
and commit 4405ff4055, squashed together)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Gen7.5 (Haswell) hardware supports primitive restart for all primitive
types. It also handles all possible primitive restart indices.
Rather than specialize both can_cut_index_handle_restart_index() and
the switch statement in can_cut_index_handle_prims() for Haswell, just
return early if the hardware is Haswell because we know it can handle
everything.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 34efd9214d)
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>
(cherry picked from commit 1569709663)
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>
(cherry picked from commit 959d076b30)
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>
(cherry picked from commit 37f278000c)
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>
(cherry picked from commit 6220cc931f)
All drivers now clamp this to the appropriate range for the bound
stencil buffer when emitting stencil state.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 53a5f11f0d)
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 978f91b829)
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit db8a84de87)
V2: Drop spurious mask with 0xff.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit c411f40cba)
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7bbe9b78ae)
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit f819ec46d5)
Clamps the stencil reference value to the range representable in the
currently-bound draw framebuffer's stencil attachment.
V2: Add spec quote.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 38f65162af)
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit d90f04a65b)
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>
(cherry picked from commit ce67fb4715)
NOTE: This is a candidate for stable branches.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 888fc7a891)
We were not allowed to say the "GT3" name, but we really needed to
have the PCI IDs because too many people had such machines, so we had
to make the GT3 machines work as GT2.
Let's just say that GT2_PLUS was a short for GT2_PLUS_1 :)
NOTE: This is a candidate for stable branches.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit f1d2b37317)
This patch adds PCI IDs for Bay Trail (sometimes called Valley View).
As far as the 3D driver is concerned, it's very similar to Ivybridge,
so the existing code should work just fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e7965598b7)
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
(cherry picked from commit d0b82b1add)
Haswell's GT3 variant offers 32kB of URB space for push constants, while
GT1 and GT2 match Ivybridge, providing 16kB. Update the code to reserve
the full 32kB on GT3.
v2: Specify push constant size correctly. I thought GT3 reinterpreted
the value as multiples of 2kB, but it doesn't. You simply have to
program an even number.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit eca2251f42)
This clarifies that the offset of 2 is actually 16 kB / 8kB units.
It also keys both computations off of a single variable, which should
make it easier to change in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
(cherry picked from commit 967514ce68)
These variables are only used within a single function, so we may as
well make them local variables.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
(cherry picked from commit 8cdb2d32ec)
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>
(cherry picked from commit 306f630e67)
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>
(cherry picked from commit 2e5a268f18)
For sampler messages, it depends on the target gen, and on gen4
SIMD16-sampler-on-SIMD8-execution we were returning 4 instead of 8 like we
should.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 3cf69b2284)
Conflicts:
(We didn't pick over the varying-index changes, so
FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7 returns 1 reg, not 4.)
src/mesa/drivers/dri/i965/brw_fs.cpp
Ian and I have tried to backport them a few times now and have hit
regressions every time. They're also performance fixes, not
bug/stability fixes, so we'll skip them for now.
Acked-by: Eric Anholt <eric@anholt.net>
All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
language requiring certain integer variables to be declared with the
"flat" keyword, but they differ in exactly *when* the rule is
enforced:
(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
type must be declared as "flat". There is no restriction on fragment
shader inputs.
(b) GLSL 1.50 through 4.30 say that fragment shader inputs having
integral type must be declared as "flat". There is no restriction on
vertex shader outputs.
(c) GLSL ES 3.00 says that both vertex shader outputs and fragment
shader inputs having integral type must be declared as "flat".
Previously, Mesa's behaviour was consistent with (a). This patch
makes it consistent with (b) when compiling desktop shaders, and (c)
when compiling ES shaders.
Rationale for desktop shaders: once we add geometry shaders, (b) really
seems like the right choice, because it requires "flat" in just the
situations where it matters. Since we may want to extend geometry
shader support back before GLSL 1.50 (via ARB_geometry_shader4), it
seems sensible to apply this rule to all GLSL versions. Also, this
matches the behaviour of the nVidia proprietary driver for Linux, and
the expectations of Intel's oglconform test suite.
Rationale for ES shaders: since the behaviour specified in GLSL ES
3.00 matches neither pre-GLSL-1.50 nor post-GLSL-1.50 behaviour, it
seems likely that this was a deliberate choice on the part of the GLES
folks to be more restrictive. Also, the argument in favor of (b)
doesn't apply to GLES, since it doesn't support geometry shaders at
all.
Some discussion about this has already happened on the Mesa-dev list.
See:
http://lists.freedesktop.org/archives/mesa-dev/2013-February/034199.html
Fixes piglit tests:
- glsl-1.30/compiler/interpolation-qualifiers/nonflat-*.frag
- glsl-1.30/compiler/interpolation-qualifiers/vs-flat-int-0{2,3,4,5}.vert
- glsl-es-3.00/compiler/interpolation-qualifiers/varying-struct-nonflat-{int,uint}.frag
Fixes oglconform tests:
- glsl-q-inperpol negative.fragin.{int,uint,ivec,uvec}
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
(cherry picked from commit dfb57e7d1b)
This is the opportunity that radeon and intel drivers rely on for flushing
render targets that may get reused as textures. Before EGL, that only
happened for GL_TEXTURE attachments.
Fixes piglits:
KHR_gl_renderbuffer_image/renderbuffer-texture
OES_EGL_image/renderbuffer-texture
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit c810e67c55)
Before, if we failed to allocate the index buffer we'd silently
return from st_draw_vbo() without drawing anything. We should
raise GL_OUT_OF_MEMORY to give some indication that something went
wrong.
Note: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
(cherry picked from commit e0144019c0)
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for drivers that
use Mesa IR.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Fabian Bieler <fabianbieler@fastmail.fm>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 4e9c7f9c5a)
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for gallium drivers.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Fabian Bieler <fabianbieler@fastmail.fm>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit e1ff753d67)
Emit EGL_BAD_CONTEXT if the user passes a context to
eglCreateImageKHR(type=EGL_ANDROID_image_native_buffer).
From the EGL_ANDROID_image_native_buffer spec:
* If <target> is EGL_NATIVE_BUFFER_ANDROID and <ctx> is not
EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
Note: This is a candidate for the stable branches.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 2878f4685c)
Fixes infinite loop on startup in Portal and Left 4 Dead 2.
NOTE: This is a candidate for the 9.0 and 9.1 branches.
(cherry picked from commit 14a0bb81fe)
This like the fifth attempt to fix the issue.
Also with the new "validating" flag, we can set recalculate_inputs to FALSE
earlier in vbo_bind_arrays, because _mesa_update_state won't change it.
NOTE: This is a candidate for the stable branches.
v2: fixed a typo
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 8eef6ad2e2)
