- Jun 25, 2014
-
-
Carl Worth authored
Which is ready to go.
-
Carl Worth authored
In preparation for the 10.2.2 release.
-
- Jun 23, 2014
-
-
Fix an off by one in the texture unit walk during texblend setup on gen2. This caused the last enabled texunit to be skipped resulting in totally messed up texturing. This is a regression introduced here: commit 1ad443ec Author: Eric Anholt <eric@anholt.net> Date: Wed Apr 23 15:35:27 2014 -0700 i915: Redo texture unit walking on i830. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit ca55a1aa)
-
When the last context in a share group is destroyed, the hash table containing all of the shader programs (ctx->Shared->ShaderObjects) is destroyed, throwing away all of the shader programs. Using a static variable to store program IDs ends up holding on to them after this, so we think we still have a compiled program, when it actually got destroyed. _mesa_UseProgram then hits GL errors, since no program by that ID exists. Instead, store the program IDs in the context, so we know to recompile if our context gets destroyed and the application creates another one. Fixes es3conform tests when run without -minfmt (where it creates separate contexts for testing each visual). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77865 Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a20994d6) Conflicts: src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
-
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)
-
This is just a hack, it should be possible to create a temporary zeta surface and render to that instead. However that's more complicated and this avoids the render being entirely broken and errors being reported by the card. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 25182e24)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c092c46b)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5af80f62)
-
Commit c1c1cf5f added infrastructure for saving and restoring draw buffer state. However, it universially used MAX_DRAW_BUFFERS, but many drivers support far fewer than that at limit. For example, the radeon and i915 drivers only support 1. Using MAX_DRAW_BUFFERS causes meta to generate GL errors. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80115 Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> [on Broadwell] Tested-by:
<jpsinthemix@verizon.net> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit cc219d1d)
-
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)
-
It's about as broken as on later UVD revisions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66452 Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Christian König <christian.koenig@amd.com> (cherry picked from commit 6cd30f5d)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit af05270c)
-
Like on Haswell, we need to use 8x4 aligned rectangle primitives for hierarchical depth buffer resolves and depth clears. See the comments in brw_blorp.cpp's brw_hiz_op_params() constructor. (The Broadwell documentation confirms that this is still necessary.) This patch makes the Broadwell code follow the same behavior as Chad and Jordan's Gen7 BLORP code. Based on a patch by Topi Pohjolainen. This fixes es3conform's framebuffer_blit_functionality_scissor_blit test, with no Piglit regressions. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 49659ad9)
-
We've used the LD sampler message for pull constant loads on earlier hardware for some time, and also were already using it for the FS on Broadwell. This patch makes us use it for Broadwell VS/GS as well. I believe that when I wrote this code in 2012, we still used the data port in some cases, and I somehow neglected to convert it while rebasing. Improves performance in GLBenchmark 2.7 Egypt by 416.978% +/- 2.25821% (n = 17). Many other applications should benefit similarly: this speeds up uniform array access in the VS, which is commonly used for skinning shaders, among other things. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Tested-by:
Ben Widawsky <ben@bwidawsk.net> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5d8e246a)
-
Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 847abacc)
-
I actually added MOCS support for these things, but forgot to delete the corresponding perf_debug() warnings. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d053a05e)
-
Somehow I missed this when adding all of the other MOCS values. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7f256c1c)
-
When faced with code such as: mov vgrf31.0:UD, 960D mov vgrf31.1:UD, vgrf30.xxxx:UD The dead code eliminator didn't consider reg_offsets, so it decided that the second instruction was writing was writing to the same register as the first one, and eliminated the first one. But they're actually different registers. This fixes INTEL_DEBUG=shader_time for vertex shaders. In the above code, vgrf31.0 represents the offset into the shader_time buffer where the data should be written, and vgrf31.1 represents the actual time data. With a completely undefined offset, results were...unexpected. I think this is probably one of the few cases (maybe only case) where we generate multiple MOVs to a large VGRF. Normally, we just use them as texturing results; the other SEND-from-GRF uses a size 1 VGRF. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79029 Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit d0575d98)
-
Cc: "10.2" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit ffe609cc)
-
Commit e62b7d38 (configure: autodetect video state-trackers when non swrast driver is present) added a check that caused the autodetection to be omitted when we have the swrast gallium driver. Whereas it should have skipped the VL targets when only swrast was selected. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79907 Cc: "10.2" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> (cherry picked from commit 816d392b)
-
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)
-
We need to invalidate the live intervals when inserting new instructions. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 237aac39)
-
When walking backwards, we want to stop at the head sentinel, which is where scan_inst->prev->prev == NULL, not scan_inst->prev == NULL. Fixes random crashes, as well as valgrind errors. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit ecc78eab)
-
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)
-
I used commit bc8b07a6 as reference, and only the droid_display_vtbl had this issue. This fixes: src/egl/drivers/dri2/platform_android.c:641:29: error: 'dri2_fallback_pixmap_surface' undeclared here (not in a function) 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 6980cae6)
-
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)
-
There is a short-immediate version as well, but it should never end up getting used since it would have gotten folded earlier. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bd7dd3ed)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7a673187)
-
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4a3a71a1)
-