glIsQuery is supposed to return false for names returned by glGenQueries
until their first use. BeginQuery is a use, but QueryCounter is also a
use.
From the ARB_timer_query spec:
"A timer query object is created with the command
void QueryCounter(uint id, enum target);
[...] If <id> is an unused query object name, the
name is marked as used [...]"
Fixes Piglit's spec/ARB_timer_query/query-lifetime.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 7950315583)
Just like all other mesa libraries...
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit b47bde0079)
Just like all other gallium targets...
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit aeb9c9e4b0)
As of "2f142d59 build: Add --enable-gallium-osmesa flag." the pkgconfig
file from classic osmesa is no longer installed when building gallium
osmesa, so copy it to gallium osmesa and install the copy instead.
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit c811190430)
enums were being converted twice resulting in incorrect values.
The extra conversion has been removed and the redundant assert is
removed also.
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit f0072e3c6b)
The previous value of (GLuint64) ~0 has some problems:
GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has
to be queried via GetInteger64v(), which returns a GLint64. This means
that some applications are likely to treat it as a signed integer, where
~0 means -1. Negative values are nonsensical and problematic.
When interpreted correctly, ~0 translates to about 0.58 million years,
which seems rather excessive.
This patch changes it to 0x1fff7fffffff, which is about 1.11 years.
This is still plenty long, and is the same as both an int64 and uint64.
Applications that accidentally store it in a 32-bit int/unsigned also
get a non-negative value, which is again the same as both int and
unsigned. This value was suggested by Ian Romanick.
v2: Add the ULL prefix on the constant (suggested by Ian).
Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit a27180d0d8)
This same message is printed in the validate_matrix_layout_for_type
function.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
(cherry picked from commit 77373e020e)
The variable means that UBO qualifiers are allowed in a particular
context (e.g., not allowed in a struct field declaration), rather than a
particular set of UBO qualifiers are valid.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
(cherry picked from commit 1a45db9705)
Fixes inconsistent failure of gles2conform/GL2Tests/glUniform/glUniform.test
under gnome-shell. What follows is a description of the bug and its fix.
When intel_update_renderbuffers() allocates a miptree for a winsys
renderbuffer, it propagates the renderbuffer's format to become also the
miptree's format.
If the winsys color buffer format is SARGB, then, in the first call to
eglMakeCurrent, intel_gles3_srgb_workaround() changes the renderbuffer's
format to ARGB. That is, it changes the format from sRGB to non-sRGB.
However, it changes the renderbuffer's format *after*
intel_update_renderbuffers() has allocated the renderbuffer's miptree.
Therefore, when eglMakeCurrent returns, the miptree format (SARGB)
differs from the renderbuffer format (ARGB).
If the X server reallocates the color buffer,
intel_update_renderbuffers() will create a new miptree for the
renderbuffer. The new miptree's format (ARGB) will differ from old
miptree's format (SARGB). This mismatch between old and new miptrees
causes bugs.
Fix the bug by moving intel_gles3_srgb_workaround() to occur *before*
intel_update_renderbuffers().
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67934
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit ce8639a766)
They are defined as constant 0.0/0.0/1.0.
Three more little piglits.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 237cb074cb)
The Gallium implementation is apparently not ready for regular
consumption, so as much as I hate adding more build-time options, here's
another.
Acked-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 2f142d596f)
Previously, copy propagation would cause bitcast_f2u(abs(float)) to
be performed in a single step, but the application of source modifiers
(abs, neg) happens after type conversion, leading to incorrect results.
That is, for bitcast_f2u(abs(float)) we would in fact generate code to
do abs(bitcast_f2u(float)).
For example, whereas bitcast_f2u(abs(float)) might result in a register
argument such as
(abs)g2.2<0,1,0>UD
v2: Set interfered = true and break in register_coalesce instead of
returning false.
Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
(cherry picked from commit 9c48ae751a)
Necessary to avoid combining a bitcast and a modifier into a single
operation. Otherwise if safe, the MOV should be removed by
copy-propagation or register coalescing.
With this and the next patch, there are only four changes in shader-db:
all a single extra instruction. The code does something like
mov a.w, -b.x
and copy propagation doesn't work because it only handles no-op
swizzles. Seems acceptable, given the known limitation of our copy
propagation.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
(cherry picked from commit 0ae9ca12a8)
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Tested-by: Brian Paul <brianp at vmware.com>
Reviewed-by: Brian Paul <brianp at vmware.com>
(cherry picked from commit 63ac68bae3)
Writing to the source directory can cause multiple parallel builds
from the same source to fail. Create the temporary files in the
build directory.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 10aa3677cc)
The NVIDIA driver doesn't expose them, and piglit's
arb_texture_compression-invalid-formats expects them to not be there.
This, with the previous commit, fixes piglit
arb_texture_compression-invalid-formats.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit f53b634807)
There is no extension for this format in desktop GL, so an application
can't give the format back to glCompressedTexImage2D.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 40550c8ced)
This is required by the spec, and it's a bit tricky because the default
precision is scoped. As a result, I'm slightly abusing the symbol
table.
Fixes piglit no-default-float-precision.frag tests and the piglit
default-precision-nested-scope-0[1234].frag tests that are currently on
the piglit mailing list for review.
On IRC I got confirmation from cwabbot that ARM (Mali T6xx and T400)
enforces this requirement and from kusma that NVIDIA (Tegra2) enforces
this requirement. We should be safe from regressing shipping
applications.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit cabd45773b)
We never noticed this before because we previously didn't enfoce GLSL ES
fragement shader requirements that precision be defined. There may also
have been some interaction here with the addition of
GL_ARB_shading_language_420pack, but it doesn't appear to me that it
added any new bugs (just perhaps uncovered some old ones).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 73e2d69792)
This is used by the next patch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit b15b62c54c)
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory. So,
create the directories just in case.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 76feef0823)
The LLVM R600 backend currently always uses separate VGPRs for these.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68162
(Centroid interpolation is identical to center interpolation without
multisampling, so the shader hardware was only pre-loading one set of
interpolation coefficients, and the pixel shader code was using
uninitialized values as the centroid interpolation coefficients)
Cc: mesa-stable@lists.freedesktop.org
Tested-by: Laurent Carlier <lordheavym@gmail.com>
(cherry picked from commit be301f707e)
This should fix missing symbols in a osmesa built against shared glapi
osmesa build. All opengl exports were missing that are defined in the
static glapi, so link against both to fix this.
I could swear I've done this before, maybe there was a glitch in the matrix.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47824
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
(cherry picked from commit 603160d4c0)
We recently proposed a new syntax for stable-patch nominations such as:
CC: "9.2 and 9.1" <mesa-stable@lists.freedesktop.org>
and this has already appeared in the wild.
So we extend the regular expression to pick this up as well.
(cherry picked from commit c6f3036179)
We recently adopted a new convention that patches can be nominated for the
stable branch by including a line in the commit message as follows:
CC: mesa-stable@lists.freedesktop.org
This is a convenient syntax as "git send-email" will notice this line and
automatically copy the resulting patch email to the mesa-stable mailing list.
Here we extend the regular expression in the get-pick-list.sh script to also
notice this pattern, (as well as the traditional "NOTE: This patch is a
candidate..." form.
(cherry picked from commit 122d8d2f5a)
The first field of a record in a UBO has the aligment of the record
itself.
Fixes piglit vs-struct-pad, fs-struct-pad, and (with the patch posted to
the piglit list that extends the test) layout-std140.
NOTE: The bit of strangeness with the version of visit_field without the
record_type poitner is because that method is pure virtual in the base
class. The original implementation of the class did this to ensure
derived classes remembered to implement that flavor. Now they can
implement either flavor but not both. I don't know a C++ way to enforce
that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68195
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org
(cherry picked from commit 574e4843e9)
The outer-most record is passed into the visit_field method for
the first field. In other words, in the following structure:
struct S1 {
vec4 v;
float f;
};
struct S {
S1 s1;
S1 s2;
};
uniform Ubo {
S s;
};
s.s1.v would get record_type = S (because s1.v is the first non-record
field in S), and s.s2.v would get record_type = S1. s.s1.f and s.s2.f
would get record_type = NULL becuase they aren't the first field of
anything.
This new overload isn't used yet, but the next patch will add several
uses.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org
(cherry picked from commit 5ac884fd9f)
Continue to allow them in GLSL 1.10 because the spec allows it.
Generate an error in all other versions because the specs specifically
disallow it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit d9bb8b7b56)
Once the compiler proplerly checks for default precision qualifiers,
these shaders will cease to compile.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 5ac247a73e)
Tested by examining generated TGSI shaders from piglit/glsl-routing.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Henri Verbeet <hverbeet@gmail.com>
Tested-by: Henri Verbeet <hverbeet@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit d13003f544)
