- Jun 25, 2014
-
-
Carl Worth authored
-
Carl Worth authored
In preparation for the 10.1.6 release.
-
- Jun 24, 2014
-
-
Carl Worth authored
This patch is not needed on the 10.1 branch, (just 10.2), as confirmed by Emil.
-
Some operations (e.g. OP_MUL/OP_MAD/OP_EXTBF) might have a subop set. After folding, make sure that it is cleared Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 3164bfc7)
-
- Jun 23, 2014
-
-
The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 604e54de)
-
EGL 1.4 Specification says that eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT) can be used to release the current thread's ownership on the surfaces and context. MESA's egl implementation was only accepting the parameters when the KHR_surfaceless_context extension is supported. [chadv] Add quote from the EGL 1.4 spec. Cc: "10,1, 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (cherry picked from commit 0ca0d574)
-
Prior to GLX 1.3 there was the glxMakeCurrent() function that took a single drawable handle. The Drawable could be either a bare XID for a Window or an XID for a glxpixmap. GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for reading, one for writing. Nowadays the old glxMakeCurrent call is implemented as a call to glxMakeContextCurrent with the single handle duplicated. Because of this it is allowed to use a plain-old Window ID as an argument to glxMakeContextCurrent, although nobody really documents this sort of thing. The manpage for the NEW call specifies the arguments as GLXPixmaps, but the actual code accepts Window XIDs too, and handles them correctly. Similarly, the glxSelectEvents function can also take a bare Window XID. The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never tested swap events with a bare Window XID. That is what my app was doing. The swap_events code worked with Window XIDs in mesa 7.x.y. The new code added in versions 8, 9, and 10 assumes that all buffer swap events have a GLXPixmap associated with them. Because of the historical quirks above, this is not true. Swap events for bare Window XIDs do NOT have a glxpixmap resulting in a segfault. Any app that uses the old school glxMakeCurrent call with a Window XID while trying to use swap_events will crash when the libs try to lookup the nonexistent GLXPixmap associated with the incoming swap event. I believe that the people who wrote the spec overlooked this, because the "sbc" field comes from the OML_sync extension that is defined in terms of glxpixmaps only. v2 (idr): Formatting changes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 86bd2196)
-
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 96a95f48)
-
An LLVMContext should only be accessed by a single and using the global context was causing crashes in multi-threaded environments. Now we use a separate context for each compile. Reviewed-by: Francisco Jerez <currojerez@riseup.net> CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4aa128a1)
-
https://bugs.freedesktop.org/show_bug.cgi?id=78581 CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0cc391f0)
-
A drawable size of 0x0 means that we don't have buffers for a drawable yet, not that we have a zero-sized buffer. Core mesa shouldn't be optimizing out drawing based on buffer size, since the draw call could be what triggers the driver to go and get buffers. As discussed in the referenced bug report, the optimization was added as part of a scatter-shot attempt to fix a different problem. There's no other example in mesa core of using the buffer size in this way. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005 Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 7928b946)
-
When a multisampled texture is used for sampling the fast clear color value needs to be programmed into the surface state. This was being left as all zeroes so if the surface was cleared to a value other than black then it wouldn't work properly. This doesn't matter for single-sample textures because in that case the MCS buffer is resolved before it is used as a texture source. https://bugs.freedesktop.org/show_bug.cgi?id=79729 Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 765efeef)
-
LLVM is enabled by default for some architectures, but the test was failing before that. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 2d399bb1)
-
_mesa_streaming_load_memcpy is defined in main/streaming-load-memcpy.c I'm adding it to the dricore lib Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 357a8b6f)
-
This fixes: include/c11/threads_posix.h: In function 'cnd_timedwait': include/c11/threads_posix.h:140:21: error: storage size of 'abs_time' isn't known Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 6eb3888c)
-
Fixes: src/egl/drivers/dri2/platform_android.c:38: include/GL/internal/dri_interface.h:51:17: fatal error: drm.h: No such file or directory Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 4dc5545e)
-
This fixes: In file included from /home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_exec_api.c:445:0: /home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_attrib_tmp.h:28:38: fatal error: util/u_format_r11g11b10f.h: No such file or directory Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 0048483f)
-
This fixes src/egl/drivers/dri2/platform_android.c:664: error: undefined reference to 'loader_set_logger' src/egl/drivers/dri2/platform_android.c:678: error: undefined reference to 'loader_get_driver_for_fd' Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit a49ebfab)
-
Fixes linker error: ld: .../libmesa_dri_common_intermediates/libmesa_dri_common.a(dri_util.o): in function globalDriverAPI:dri_util.c(.data.rel+0x0): error: undefined reference to 'driDriverAPI' As an example, you can see that mesa_dri_drivers also uses common/libmegadriver_stub (src/mesa/drivers/dri/Makefile.am) The _stub part might be confusing, but it actually provides the dri-driver shared lib constructor, megadriver_stub_init, which will later on load the real platform dependent part and call l __driDriverGetExtensions_<platform> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit aba0f152)
-
So that android part can also use $(megadriver_stub_FILES) Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit eb3f80db)
-
Cc: Tom Stellard <thomas.stellard@amd.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> (cherry picked from commit 93257a56)
-
A recent ApiTrace change, that tries to dump more buffer state causes Mesa from my distro (10.1.4) to segfaults here. I haven't actually confirm this fixes it (I can't repro on master), but it seems a good idea to be defensive here anyway. Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit eb58aa9c)
-
Same as b026b6bb, but COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE. Ideally we wouldn't munge the incoming state, so that we wouldn't need to unmunge it back on glGet*. But the array size state is copied and referred in many places, many of which couldn't take an GLenum like GL_BGRA instead of a plain integer. So just hack around on glGet*, to ensure there is no risk of introducing regressions elsewhere. This bug causes problems to Apitrace, resulting in wrong traces. See https://github.com/apitrace/apitrace/issues/261 for details. Tested with piglit arb_vertex_array_bgra-get, which was created for this purpose. Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e3e13d6b)
-
Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 53468dee)
-
- Jun 07, 2014
-
-
Carl Worth authored
Immediately after tagging the commit used to create the tar files.
-
Carl Worth authored
-
Carl Worth authored
In preparation for the 10.1.5 release, of course.
-
Carl Worth authored
The function being modified does not exist in 10.1.
-
- Jun 02, 2014
-
-
Carl Worth authored
The second of these two is simply a "git revert" of the first. So skipping both of them gives us the same final result in a simpler way.
-
Framebuffers can have NULL attachments since a while. llvmpipe handled that properly for lp_rast_shade_quads_mask but it seems the change didn't make it to lp_rast_shade_tile. This fixes piglit fbo-drawbuffers-none test (though I need to increase the FB_SIZE from 32 to 256 so the tris cover some tiles fully). https://bugs.freedesktop.org/show_bug.cgi?id=79421 Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> (cherry picked from commit 57686814)
-
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Pavel Popov <pavel.e.popov@intel.com> (cherry picked from commit d292d402)
-
The call to get_variable_being_redeclared() may delete 'var' so we can't reference var->name afterward. We fix that by examining the var's name before making that call. Fixes valgrind warnings and possible crash when running the piglit tests/spec/glsl-1.30/execution/clipping/vs-clip-distance-in-param.shader_test test (and probably others). Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit f9cecca7)
-
v2: Do not wrap the code in ifdef HAVE_DRI3 (suggested by Keith) Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit eb2241f8)
-
The glGetGraphicsResetStatusARB from ARB_robustness extension always returns GUILTY_CONTEXT_RESET_ARB and never returns NO_ERROR for guilty context with LOSE_CONTEXT_ON_RESET_ARB strategy. This is because Mesa returns GUILTY_CONTEXT_RESET_ARB if batch_active !=0 whereas kernel driver never reset batch_active and this variable always > 0 for guilty context. The same behaviour also can be observed for batch_pending and INNOCENT_CONTEXT_RESET_ARB. But ARB_robustness spec says: If a reset status other than NO_ERROR is returned and subsequent calls return NO_ERROR, the context reset was encountered and completed. If a reset status is repeatedly returned, the context may be in the process of resetting. 8. How should the application react to a reset context event? RESOLVED: For this extension, the application is expected to query the reset status until NO_ERROR is returned. If a reset is encountered, at least one *RESET* status will be returned. Once NO_ERROR is encountered, the application can safely destroy the old context and create a new one. The main problem is the context may be in the process of resetting and in this case a reset status should be repeatedly returned. But looks like the kernel driver returns nonzero active/pending only if the context reset has already been encountered and completed. For this reason the *RESET* status cannot be repeatedly returned and should be returned only once. The reset_count and brw->reset_count variables can be used to control that glGetGraphicsResetStatusARB returns *RESET* status only once for each context. Note the i915 triggers reset_count twice which allows to return correct reset count immediately after active/pending have been incremented. v2 (idr): Trivial reformatting of comments. Signed-off-by: Pavel Popov <pavel.e.popov@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 8dc4a98c)
-
glFramebufferRender(..., GL_DEPTH_STENCIL_ATTACHMENT, ..., 0) only detached the depth buffer and not the stencil buffer. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=79115 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 846c715a)
-
- May 22, 2014
-
-
These instructions can come in either through IMUL_HI/UMUL_HI TGSI opcodes, or from OP_DIV constant folding. Also make sure that the constant foldings which delete the original instruction still get counted as having done something. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> (cherry picked from commit d2a3de19)
-
Retrieving the high 32 bits of a signed multiply is rather annoying. It appears that the simplest way to do this is to compute the absolute value of the arguments, and perform a u32 x u32 -> u64 operation. If the arguments' signs differ, then negate the result. Since there is no u64 support in the cvt instruction, we have the perform the 2's complement negation "by hand". This logic can come into use by the IMUL_HI instruction (very unlikely to be seen), as well as from constant folding of division by a constant. Fixes dolphin's divisions by 255. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> (cherry picked from commit d3a5cf05)
-
- May 20, 2014
-
-
Carl Worth authored
-
Carl Worth authored
After making the tar files.
-
Carl Worth authored
-