- Feb 03, 2014
-
-
Carl Worth authored
Just before making the actual release.
-
Carl Worth authored
In preparation for the upcoming 10.0.3 release.
-
_mesa_streaming_load_memcpy is also needed even if assembling is disabled Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 1cdeeef6)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72708 Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Lauri Kasanen <cand@gmx.com> (cherry picked from commit fcefdc9a)
-
It readds the GLXContextID typedef, but under #ifndef GLX_VERSION_1_3. Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=11454 (Backported from commit 3f3aafbf)
-
- Jan 31, 2014
-
-
This patch handles the use of 'centroid' qualifier with 'in' variables in a fragment shader when persample shading is enabled. Per sample shading for the whole fragment shader can be enabled by: glEnable(GL_SAMPLE_SHADING) or using {gl_SamplePosition, gl_SampleID} builtin variables in fragment shader. Explaining it below in more detail. /* Enable sample shading using OpenGL API */ glEnable(GL_SAMPLE_SHADING); glMinSampleShading(1.0); Example fragment shader: in vec4 a; centroid in vec4 b; main() { ... } Variable 'a' will be interpolated at sample location. But, what interpolation should we use for variable 'b' ? ARB_sample_shading recommends interpolation at sample position for all the variables. GLSL 400 (and earlier) spec says that: "When an interpolation qualifier is used, it overrides settings established through the OpenGL API." But, this text got deleted in later versions of GLSL. NVIDIA's and AMD's proprietary linux drivers (at OpenGL 4.3) interpolates at sample position. This convinces me to use the similar approach on intel hardware. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> (cherry picked from commit f5cfb4ae) and i965: Ignore 'centroid' interpolation qualifier in case of persample shading I missed this change in commit f5cfb4ae. It fixes the incorrect rendering caused in Dolphin Emulator. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73915 Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Markus Wick <wickmarkus@web.de> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit dc2f94bc)
-
Current implementation of arb_sample_shading doesn't set 'Barycentric Interpolation Mode' correctly. We use pixel barycentric coordinates for per sample shading. Instead we should select perspective sample or non-perspective sample barycentric coordinates. It also enables using sample barycentric coordinates in case of a fragment shader variable declared with 'sample' qualifier. e.g. sample in vec4 pos; A piglit test to verify the implementation has been posted on piglit mailing list for review. V2: Do not interpolate all the 'in' variables at sample position if fragment shader uses 'sample' qualifier with one of them. For example we have a fragment shader: #version 330 #extension ARB_gpu_shader5: require sample in vec4 a; in vec4 b; main() { ... } Only 'a' should be sampled at sample location, not 'b'. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> (cherry picked from commit a92e5f7c)
-
Carl Worth authored
For 3 of the 4, I was already ignoring them since they were not picking cleanly. Now, Anuj has explicitly requested they be ignored since they all depend on a series that is not yet on the 10.0 branch.
-
roundf is not available on MSVC. (cherry picked from commit bba8f105)
-
This is a squash of three related cherry-picks from master. [PATCH 1/3] i965/gen6/blorp: Set need_workaround_flush immediately after primitive This patch makes the workaround code in gen6 blorp follow the pattern established in the regular draw path. It shouldn't result in any behavioral change. On gen6, there are two places where we emit 3D_CMD_PRIM: brw_emit_prim() and gen6_blorp_emit_primitive(). brw_emit_prim() sets need_workaround_flush immediately after emitting the primitive, but blorp does not. Blorp sets need_workaround_flush at the bottom of brw_blorp_exec(). This patch moves the need_workaround_flush from brw_blorp_exec() to gen6_blorp_emit_primitive(). There is no need to set need_workaround_flush in gen7_blorp_emit_primitive() because the workaround applies only to gen6. Reviewed-by: Paul Berry <stereotype441@gmail.com> Signed-off-by: Chad Versace <chad.versace@linux.intel.com> (cherry picked from commit 5e0cd58d) [PATCH 2/3] i965/gen6/blorp: Set need_workaround_flush at top of blorp Unconditionally set brw->need_workaround_flush at the top of gen6 blorp state emission. The art of emitting workaround flushes on Sandybridge is mysterious and not fully understood. Ken and I believe that intel_emit_post_sync_nonzero_flush() may be required when switching from regular drawing to blorp. This is an extra safety measure to prevent undiscovered difficult-to-diagnose gpu hangs. I verified that on ChromeOS, pre-patch, need_workaround_flush was not set at the top of blorp, as Paul expected. To verify, I inserted the following debug code at the top of gen6_blorp_exec(), restarted the ui, and inspected the logs in /var/log/ui. The abort gets triggered so early that the browser never appears on the display. static void gen6_blorp_exec(...) { if (!brw->need_workaround_flush) { fprintf(stderr, "chadv: %s:%d\n", __FILE__, __LINE__); abort(); } ... } CC: Kenneth Graunke <kenneth@whitecape.org> CC: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paul Berry <stereotype441@gmail.com> Signed-off-by: Chad Versace <chad.versace@linux.intel.com> (cherry picked from commit 6a5c86f4) [PATCH 3/3] i965/gen6/blorp: Remove redundant HiZ workaround Commit 1a928816 added extra flushes to fix a HiZ hang in WebGL Google Maps. With the extra flushes emitted by the previous two patches, the flushes added by 1a928816 are redundant. Tested with the same criteria as in 1a928816: by zooming in and out continuously for 2 hours on Sandybridge Chrome OS (codename Stumpy) without a hang. CC: Kenneth Graunke <kenneth@whitecape.org> CC: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paul Berry <stereotype441@gmail.com> Signed-off-by: Chad Versace <chad.versace@linux.intel.com> (cherry picked from commit 90368875) Conflicts: src/mesa/drivers/dri/i965/gen6_blorp.cpp
-
- Jan 28, 2014
-
-
Otherwise an application that requested an OpenGL ES 1.x context would actually get a desktop OpenGL context. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 33214679)
-
This is necessary to prevent the next SURFACE_SYNC packet from hanging the GPU. https://bugs.freedesktop.org/show_bug.cgi?id=73418 Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: "9.2" "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d51dbe04)
-
For a variety of reasons mmap (selinux and pax to name a few) and can fail and with current code. This will result in a crash in the driver, if not worse. This has been the case since the inception of the gallium copy of rtasm. Cc: 9.1 9.2 10.0 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73473 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> (cherry picked from commit 4dd445f1)
-
Carl Worth authored
These depend on code which does not exist on the stable branch.
-
Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 66ef8feb) Conflicts: src/glsl/glcpp/glcpp-parse.y
-
Carl Worth authored
The comments describe the reasons for each being excluded.
-
We were calling draw_total_vs_outputs() too early. The call to draw_pt_emit_prepare() could result in the vertex size changing. So call draw_total_vs_outputs() after draw_pt_emit_prepare(). This fix would seem to be needed for the non-LLVM code as well, but it's not obvious. Instead, I added an assertion there to try to catch this problem if it were to occur there. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926 Cc: 10.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: José Fonseca <jfonseca@vmware.com> (cherry picked from commit ad814d04) Conflicts: src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
-
- Jan 26, 2014
-
-
Simple shaders such as: void splat(vec2 v, float f) { v[0] = v[1] = f; } failed to compile with the following error: error: value of type vec2 cannot be assigned to variable of type float First, we would process v[1] = f, and transform: LHS: (expression float vector_extract (var_ref v) (constant int (1))) RHS: (var_ref f) into: LHS: (var_ref v) RHS: (expression vec2 vector_insert (var_ref v) (constant int (1)) (var_ref f)) Note that the LHS type is now vec2, not a float. This is surprising, but not the real problem. After emitting assignments, this ultimately becomes: (declare (temporary) vec2 assignment_tmp) (assign (xy) (var_ref assignment_tmp) (expression vec2 vector_insert (var_ref v) (constant int (1)) (var_ref f))) (assign (xy) (var_ref v) (var_ref assignment_tmp)) We would then return (var_ref assignment_tmp) as the rvalue, which has the wrong type---it should be float, but is instead a vec2. To fix this, we simply return (vector_extract (var_ref assignment_temp) <the appropriate channel>) to pull out the desired float value. Fixes Piglit's chained-assignment-with-vector-constant-index.vert and chained-assignment-with-vector-dynamic-index.vert tests. Cc: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74026 Reported-by: Dan Ginsburg <dang@valvesoftware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 44a86e2b)
-
When processing assignments, we have both an LHS and RHS. At a glance, "lhs_expr" clearly refers to the LHS, while a generic name like "expr" is ambiguous. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 6c158e11)
-
OpenGL with ARB_ES2_compatibility allows shaders that specify #version 100. This fixes the Khronos OpenGL test(Texture_Rectangle_Samplers_frag.test) failure. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit c907595b)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73956 Cc: 10.0 <mesa-stable@lists.freedesktop.org> Tested-by: Ahmed Allam <ahmabdabd@hotmail.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit f7c118ff)
-
This fixes a serious regression introduced in 4e549ddb. Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit d40532f2)
-
NV3x cards don't support NPOT textures. Technically this restriction could be worked around, but since it also doesn't expose any video decoding hw, just turn it off entirely. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: 10.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 00e4314f)
-
The textures array is defined as a number of NV50_MAX_PIPE_CONSTBUFS per shader stage. Currently the nv50 driver handles only 3 shader stages, thus we wreck chaos when accessing array-out-of-bounds. Cc: 9.1 9.2 10.0 <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 12e744ab)
-
The textures array is defined as a number of PIPE_MAX_SAMPLERS per shader stage. Currently nv50 driver handles only 3 shader stages, thus we wreck chaos when accessing array-out-of-bounds. Fixes a segfault in piglit/bin/arb_texture_buffer_object-data-sync -fbo -auto Cc: 9.1 9.2 10.0 <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit d606ca37)
-
Commit c1397080 (mesa: GL_EXT_secondary_color is not optional) changed CHECK_EXTENSION2(EXT_secondary_color, ARB_vetex_program, cap) to CHECK_EXTENSION(ARB_vertex_program, cap) However CHECK_EXTENSION2 checks that either extension is available, not both. Remove the extension check entirely since the intent was for it to always be enabled. v2: Fix glGet*(GL_COLOR_SUM) too. Suggested by Ian. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 739dc95e)
-
v2: Change comment style CC: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit ce352889)
-
The radeonsi code was not cleaning up either of these items leading to leaked memory. v2: Move cleanup to r600_common_context_cleanup instead of duplicating the logic for SI CC: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit 5ac3229f) Conflicts: src/gallium/drivers/radeon/r600_pipe_common.c
-
The ES and desktop GL specs diverge here. Yay! In desktop OpenGL, the driver can perform online compression of uncompressed texture data. GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats that it could ask the driver to compress with some expectation of quality. The GL_ARB_texture_compression spec calls this "suitable for general-purpose usage." As noted above, this means GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not included in the list. In OpenGL ES, the driver never performs compression. GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats that the driver can receive from the application. It is the *complete* list of formats. The GL_EXT_texture_compression_s3tc spec says: "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications The queries for NUM_COMPRESSED_TEXTURE_FORMATS and COMPRESSED_TEXTURE_FORMATS include COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, and COMPRESSED_RGBA_S3TC_DXT5_EXT." Note that the addition is only to the OpenGL ES specification! Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> See-also: http://lists.freedesktop.org/archives/mesa-dev/2013-October/047439.html Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0a75909b)
-
The temporary variable used to store _ColorDrawBufferIndexes must be signed (GLint), otherwise the following conditional will be incorrectly evaluated. Leading to crashes in the driver/mesa or accessing/writing to arbitrary memory location. The bug dates back to 2009. Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit bfcf78c1)
-
_ColorDrawBufferIndexes is defined as GLint* and using a GLuint* will result in the first part of the conditional to be evaluated to true always. Unintentionally introduced by the following commit, this will result in a driver segfault if one is using an old version of the piglit test bin/clearbuffer-mixed-format -auto -fbo commit 03d848ea Author: Marek Olšák <marek.olsak@amd.com> Date: Wed Dec 4 00:27:20 2013 +0100 mesa: fix interpretation of glClearBuffer(drawbuffer) This corresponding piglit tests supported this incorrect behavior instead of pointing at it. Cc: Marek Olšák <marek.olsak@amd.com> Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 10368e14)
-
This should help with cross-compiling and multilib when $CHOST-specific llvm-config is expected rather than build host default one. It will help us a bit in Gentoo where we've started using i686-pc-linux-gnu-llvm-config for 32-bit multilib LLVM. Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Signed-off-by: Michał Górny <mgorny@gentoo.org> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73100 CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5ea23763)
-
Prior to this patch, if we ran out of aperture space during brw_try_draw_prims(), we would rewind the batch buffer pointer (potentially throwing some state that may have been emitted by brw_upload_state()), flush the batch, and then try again. However, we wouldn't reset the dirty bits to the state they had before the call to brw_upload_state(). As a result, when we tried again, there was a danger that we wouldn't re-emit all the necessary state. (Note: prior to the introduction of hardware contexts, this wasn't a problem because flushing the batch forced all state to be re-emitted). This patch fixes the problem by leaving the dirty bits set at the end of brw_upload_state(); we only clear them after we have determined that we don't need to rewind the batch buffer. Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit fb6d9798)
-
Copied from the i965 driver, including the big comment. Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4e549ddb)
-
- Jan 09, 2014
-
-
We definitely want to fall through to the unsynchronized map case, instead of wasting bandwidth on a copy. Prevents a -43.2407% +/- 1.06113% (n=49) performance regression on aa10perf when teaching glamor to provide the GL_INVALIDATE_RANGE_BIT information. This is a performance fix, which I usually wouldn't cherry-pick to stable. But this was really was just a bug in the code, its presence would discourage developers from giving us the best information they can, and I think we've got fairly high confidence in the unsynchronized map path already. Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit f46563fe)
-
Fixes piglit GL_MESA_pack_invert/readpixels and GPU hangs with glamor and cairo-gl. Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit e186b927)
-
MSVC 2013 version of math.h includes an fma() function. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit e8ff08ed)
-
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better memory access order. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 8fcddd32)
-
This fixes the following compile error: src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3 overloads have similar conversions Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 067ad6e5)
-
Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 20e65c92)
-