- Jan 09, 2014
-
-
Carl Worth authored
Which will happen today.
-
Carl Worth authored
In preparation for the upcoming 10.0.2 release.
-
- Jan 03, 2014
-
-
* These make up the base of what C++ GL Haiku applications use for 3D rendering. * Not placed in includes/GL to prevent Haiku headers from getting installed on non-Haiku systems. Acked-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 56d920a5)
-
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit f50a4545)
-
The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when ir_loop::counter is non-null, it points to a fresh ir_variable that should be used as the loop counter (as opposed to an ir_variable that exists elsewhere in the instruction stream). However, previous to this patch: (1) loop_control_visitor did not create a new variable for ir_loop::counter; instead it re-used the existing ir_variable. This caused the loop counter to be double-incremented (once explicitly by the body of the loop, and once implicitly by ir_loop::increment). (2) ir_clone did not clone ir_loop::counter properly, resulting in the cloned ir_loop pointing to the source ir_loop's counter. (3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting in the ir_variable being missed by reparenting. Additionally, most optimization passes (e.g. loop unrolling) assume that the variable mentioned by ir_loop::counter is not accessed in the body of the loop (an assumption which (1) violates). The combination of these factors caused a perfect storm in which the code worked properly nearly all of the time: for loops that got unrolled, (1) would introduce a double-increment, but loop unrolling would fail to notice it (since it assumes that ir_loop::counter is not accessed in the body of the loop), so it would unroll the loop the correct number of times. For loops that didn't get unrolled, (1) would introduce a double-increment, but then later when the IR was cloned for linking, (2) would prevent the loop counter from being cloned properly, so it would look to further analysis stages like an independent variable (and hence the double-increment would stop occurring). At the end of linking, (3) would prevent the loop counter from being reparented, so it would still belong to the shader object rather than the linked program object. Provided that the client program didn't delete the shader object, the memory would never get reclaimed, and so the shader would function properly. However, for loops that didn't get unrolled, if the client program did delete the shader object, and the memory belonging to the loop counter got re-used, this could cause a use-after-free bug, leading to a crash. This patch fixes loop_control_visitor, ir_clone, and ir_hierarchical_visitor to treat ir_loop::counter the same way the back-ends treat it: as a freshly allocated ir_variable that needs to be visited and cloned independently of other ir_variables. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026 Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit d6eb4321)
-
If an ir_loop has a non-null "counter" field, the variable referred to by this field is implicitly read and written by the loop. We need to account for this in ir_variable_refcount, otherwise there is a danger we will try to dead-code-eliminate the loop counter variable. Note: at the moment the dead code elimination bug doesn't occur due to a bug in ir_hierarchical_visitor: it doesn't visit the "counter" field, so dead code elimination doesn't treat it as a candidate for elimination. But the patch to follow will fix that bug, so we need to fix ir_variable_refcount first in order to avoid breaking dead code elimination. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 9d2951ea)
-
- Jan 02, 2014
-
-
Emitting flushes before depth and hiz resolves at the top of blorp's state emission fixes the hang. Marchesin and I found the fix experimentally, as opposed to adhering to a documented hardware workaround. A more minimal fix likely exists, but this gets the job done. Fixes HiZ hangs in the new WebGL Google maps on Sandybridge Chrome OS. Tested by zooming in and out continuously for 2 hours. This patch is based on https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/8bc07bb70163c3706fb4ba5f980e57dc942f56dd CC: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70740 Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 1a928816)
-
Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0612005a)
-
The preprocessor currently accepts multiple else/elif-groups per if-section. The GLSL-preprocessor is defined by the C++ specification, which defines the following parse-rule: if-section: if-group elif-groups(opt) else-group(opt) endif-line This clearly only allows a single else-group, that has to come after any elif-groups. So let's modify the code to follow the specification. Add test to prevent regressions. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Carl Worth <cworth@cworth.org> Cc: 10.0 <mesa-stable@lists.freedesktop.org> (cherry picked from commit eb212c5a)
-
This reverts commit 136a12ac. According to belak51 on IRC, this commit broke Allegro, which would no longer compile. Applications apparently expect the GLXContextID typedef to exist in glx.h; removing it breaks them. A bit of searching around the internet revealed other complaints since upgrading to Mesa 10. Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f425d56b)
-
0x9649 is sumo2, not sumo. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> CC: "9.2" "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e2d53fac)
-
Found while tracking down memory leaks in VDPAU playback Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 3ddabe0d)
-
Prevents a potential memory leak found when tracking down something else. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 20446d0e)
-
Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 767b0f82)
-
Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0bd858d7)
-
v2: Remove unnecessary null pointer check CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e19717d0)
-
Previously we were creating a new LLVMContext every time that we called radeon_llvm_parse_bitcode, which caused us to leak the context every time that we compiled a CL program. Sadly, we can't dispose of the LLVMContext at the point that it was being created because evergreen_launch_grid (and possibly the SI equivalent) was assuming that the context used to compile the kernels was still available. Now, we'll create a new LLVMContext when creating EG/SI compute state, store it there, and pass it to all of the places that need it. The LLVM Context gets destroyed when we delete the EG/SI compute state. Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 8c9a9205)
-
Prevents a memory leak. Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a7653c19)
-
Reviewed-by: Tom Stellard <thomas.stellard@amd.com> CC: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 862f55c2)
-
This fixes another case of faulting when freeing a pipe_sampler_view that belongs to a previously destroyed context. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Jonathan Liu <net147@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 7990ab58)
-
This fixes a crash where old_view->context was already freed in the pipe_sampler_view_reference function contained in src/gallium/auxiliary/utils/u_inlines.h. As a result, the sampler_view_destroy function pointer contained 0xfeeefeee indicating freed heap memory. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Jonathan Liu <net147@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 670be71b)
-
Similar to 556a47a2, without this reading from gl_FragData[0] would cause a software fallback. Bugzilla: https://bugs.winehq.org/show_bug.cgi?id=33964 Signed-off-by: Henri Verbeet <hverbeet@gmail.com> Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit b094b3b9)
-
When adding geometry shader support, we accidentally reversed the size and offset parameters. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com> Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 51c9cfc2)
-
This patch changes the error reporting behavior for incorrect function invocation (triggered by match_function_by_name() unable to find a matching function call) from using the line number information associated to the function name term to using the line number information of the entire function expression. Fixes bug #72264. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72264 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 23d294bb)
-
This patch changes the error condition to satisfy below statement from OpenGL 4.3 core specification: "An INVALID_OPERATION error is generated if id is the name of a query object with a target other SAMPLES_PASSED, ANY_SAMPLES_PASSED, or ANY_SAMPLES_PASSED_CONSERVATIVE, or if id is the name of a query currently in progress." Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 7a73c6ac)
-
The driverPrivate pointer is opaque to the driver and we can't assume it's a struct gl_context in dri_util.c. Instead provide a helper function to set the struct gl_context flags from the incoming DRI context flags. v2 (idr): Modify the other classic drivers to also use driContextSetFlags. I ran all the piglit GLX_ARB_create_context tests with i965 and classic swrast without regressions. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1] Reviewed-by: Eric Anholt <eric@anholt.net> Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> [v1 on Gallium nouveau] Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 38366c0c)
-
This corresponding piglit tests supported this incorrect behavior instead of pointing at it. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 03d848ea)
-
On evergreen we have to reserve 1 stack element in some additional cases besides the ones mentioned in the docs, but stack size computation was recently reimplemented exactly as described in the docs by the patch that added workarounds for stack issues on EG/CM, resulting in regressions with some apps (Serious Sam 3). This patch fixes it by restoring previous behavior. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=72369 Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com> Cc: "10.0" <mesa-stable@lists.freedesktop.org> Tested-by: Andre Heider <a.heider@gmail.com> (cherry picked from commit 00faf828)
-
- Dec 13, 2013
-
-
Carl Worth authored
-
Carl Worth authored
It's so nice that this is updated in just a single place now. Thanks, Emil!
-
Carl Worth authored
I'm not sure why this change is necessary. When I've built previous tar files (such as 9.2.4) with the "make tarballs" target, they include the bin/test-driver file. But at my first attempt to build the tar files for the 10.0.1 release this file was not being included and the build failed.
-
Carl Worth authored
-
- Dec 12, 2013
-
-
First off, nv50_program only has 16 in/out varyings. However reporting 16 makes 'm' become 68 in nv50_fp_linkage_validate with the varying-packing-simple piglit test. (Subverting the assert makes it compile but fail.) With this patch, varying-packing-simple passes. See: https://bugs.freedesktop.org/show_bug.cgi?id=69155 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bad8871e)
-
cfg is now unused, remove it. Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5576ad11)
-
This readback from the frontbuffer with swrast was broken, that bug just made it more obviously broken, this fixes it by inverting the sub image gets. Also fixes a few other piglits. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72327 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72325 (for 9.2 the patches this depends on were asked to be backported separately in an email). Cc: "9.2" "10.0" mesa-stable@lists.fedoraproject.org Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 0b160423)
-
flush_with_flags, when available, allows the driver to throttle. Using this suppress input lag issues that can be observed in heavy rendering situations on non-intel cards. Signed-off-by: Axel Davy <axel.davy@ens.fr> Cc: "10.0" mesa-stable@lists.freedesktop.org (cherry picked from commit afcce46f)
-
This typically won't make a difference, since we only send the requests at wl_display_flush() time. There might be a small race with another thread calling wl_display_flush() after our commit request, but before we flush the DRI driver. Moving the commit below the DRI driver flush call looks more natural and eliminates the small race. Cc: "10.0" mesa-stable@lists.freedesktop.org (cherry picked from commit 33eb5eab)
-
We would like the compositor to receive the commited buffer as soon as possible, so it has the time to treat it, and release old ones. We shouldn't rely on the client to flush the queue for us. Signed-off-by: Axel Davy <axel.davy@ens.fr> Cc: "10.0" mesa-stable@lists.freedesktop.org (cherry picked from commit 402bf6e8)
-
- Dec 10, 2013
-
-
Kristian Høgsberg authored
If we're not using EGL_EXT_swap_buffers_with_damage, we have to damage the full extent. EGL operates on buffer coordinates, but wl_surface.damage takes surface coordinates. EGL doesn't know the buffer transformation (rotated or scaled) and can't post accurate damage in surface coordinates. The damage event however is clipped to the surface extents so we can just damage the maximum rectangle. In case of EGL_EXT_swap_buffers_with_damage, the application knows the buffer transform and is expected to pass in rectangles in surface space. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70250 Cc: "10.0" mesa-stable@lists.freedesktop.org Tested-by: U. Artie Eoff <ullysses.a.eoff@intel.com> (cherry picked from commit bce64c6c)
-
Jordan Justen authored
To help the transition period when DRI loaders are being updated to support the newer __driDriverExtensions_foo mechanism, we populate __driDriverExtensions with the extensions returned by __driDriverExtensions_foo during a library contructor function. We find the driver foo's name by using the dladdr function which gives the path of the dynamic library's name that was being loaded. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Keith Packard <keithp@keithp.com> Cc: "10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4859d492)
-