- Aug 27, 2013
-
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Matt Turner authored
Cc: 9.2 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68460 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
-
Kristian Lehmann authored
Cc: 9.2 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68544 Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit cec7b5c5)
-
Tom Stellard authored
CC: "9.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> (cherry picked from commit f3e86d4a)
-
- Aug 26, 2013
-
-
Michel Dänzer authored
The stencil values come out wrong without this for some reason. 50 more little piglits. Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 46fd81e5)
-
Kenneth Graunke authored
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 79503155)
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "9.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bac6efe8)
-
- Aug 23, 2013
-
-
Jon Severinsson authored
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 b47bde00)
-
Jon Severinsson authored
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 aeb9c9e4)
-
Jon Severinsson authored
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 c8111904)
-
Timothy Arceri authored
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 f0072e3c)
-
Kenneth Graunke authored
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 a27180d0)
-
- Aug 22, 2013
-
-
Ian Romanick authored
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59648 Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit dded321f)
-
Matt Turner authored
No longer used. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit 921ef55a)
-
Matt Turner authored
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 77373e02)
-
Matt Turner authored
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 1a45db97)
-
Lina Versace authored
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 ce8639a7)
-
Michel Dänzer authored
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 237cb074)
-
Matt Turner authored
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 2f142d59)
-
Matt Turner authored
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 9c48ae75)
-
Matt Turner authored
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 0ae9ca12)
-
- Aug 21, 2013
-
-
Maarten Lankhorst authored
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 10aa3677)
-
Ian Romanick authored
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 f53b6348)
-
Ian Romanick authored
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 40550c8c)
-
Ian Romanick authored
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 cabd4577)
-
Ian Romanick authored
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 73e2d697)
-
Ian Romanick authored
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 b15b62c5)
-
Ross Burton authored
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 76feef08)
-
Michel Dänzer authored
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 be301f70)
-
Maarten Lankhorst authored
Fixes a opengl crash in wine. Cc: "9.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> (cherry picked from commit 86751cbd)
-
Maarten Lankhorst authored
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 603160d4)
-
Andreas Boll authored
(cherry picked from commit 38903db4)
-
Andreas Boll authored
(cherry picked from commit 7eaaf624)
-
Carl Worth authored
(cherry picked from commit 7f2f6340)
-
Carl Worth authored
(cherry picked from commit 964b89e4)
-
Carl Worth authored
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 c6f30361)
-
Carl Worth authored
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 122d8d2f)
-