Re: [Mesa-dev] Gallium ARB_get_program_binary support
First BAD commit is patch [PATCH 2/5]. https://patchwork.freedesktop.org/patch/192329/ With it I get this in dmesg: [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip 9ebeafda sp a95580d4 error 4 in libc-2.26.so[7f6afcaf7000+1b1000] [34706.224082] perf: interrupt took too long (5089 > 4913), lowering kernel.perf_event_max_sample_rate to 39250 [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip d9adbd7a sp e6e1b769 error 4 in libc-2.26.so[7f2fc4777000+1b1000] [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip 78a41511 sp 1f147296 error 4 in libc-2.26.so[7ff11fa23000+1b1000] [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip ef37ae37 sp 99ce37ab error 4 in libc-2.26.so[7f0af78ff000+1b1000] [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip 813f92d2 sp 7c9305e7 error 4 in libc-2.26.so[7fee87426000+1b1000] It's in the morning, now. Here in 'OLD' Germany, near Hamburg. Good night! ;-) Dieter Am 10.12.2017 05:15, schrieb Timothy Arceri: Hi, as always thanks for testing :) Are you able to find out which patch causes the crash? I'm curious if its the ARB_get_program_binary support or if I break the regular cache when re-factoring. Thanks, Tim On 09/12/17 15:58, Dieter Nützel wrote: Hello Tim, first time ever, that I got a real regression with your GREAT work. ;-) DiRT Rally sig fault (SIGSEGV(11) with this series. (see attachment) Bad cache hit re-read? Removing .cache/mesa_shader_cache do not help. Searching for the rigth Feral (Steam?) cache dir. - Alex/James? Then I'll have to find which of the five did it. From the log I got this: [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox() called with multiple threads in process gpu-process [1209/054157:INFO:CONSOLE(0)] "The specified value '!' does not conform to the required format. The format is '#rrggbb' where rr, gg, bb are two-digit hexadecimal numbers.", source: file://localhost/home1/alexander/My%20Games/Steam/steamapps/common/DiRT%20Rally/share/FeralUI/PGOW/Core/feralUI.html (0) Installing breakpad exception handler for appid(steam)/version(1509425745) [1209/054158:INFO:CONSOLE(0)] "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.";, source: (0) [1209/054208:WARNING:x11_util.cc(1490)] X error received: serial 4814, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow) SDL2 initialised [built against 2.0.5, running with 2.0.5] DirtRally: dumped to "/home/alexander/.local/share/feral-interactive/DiRT Rally/crashes/2363a778-c194-621f-0f837dfb-191070fd.dmp" Cheers, Dieter Am 08.12.2017 10:57, schrieb Timothy Arceri: Core support in now in master so this is just a resend of the gallium patches. Resolves crash in Dead Island: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564 Branch available here: https://github.com/tarceri/Mesa.git gallium-program-binary ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: fix texture wrapping for texture gather for mirror modes
From: Roland Scheidegger
Care must be taken that all coords end up correct, the tests are very
sensitive that everything is correctly rounded. This doesn't matter
for bilinear filter (since picking a wrong texel with weight zero is
ok), and we could also switch the per-sample coords mistakenly.
While here, also optimize the coord_mirror helper a bit (we can do the
mirroring directly by exploiting float rounding, no need for fixing up
odd/even manually).
I did not touch the mirror_clamp and mirror_clamp_to_border modes.
In contrast to mirror_clamp_to_edge and mirror_repeat these are legacy
modes. They are specified against old gl rules, which actually does
the mirroring not per sample (so you get swapped order if the coord
is in the mirrored section). I think the idea though is that they should
follow the respecified mirror_clamp_to_edge rules so the order would be
correct.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 242 +++---
1 file changed, 169 insertions(+), 73 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index b67a089..3605c77 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -218,34 +218,42 @@ lp_build_sample_texel_soa(struct lp_build_sample_context
*bld,
/**
- * Helper to compute the mirror function for the PIPE_WRAP_MIRROR modes.
+ * Helper to compute the mirror function for the PIPE_WRAP_MIRROR_REPEAT mode.
+ * (Note that with pot sizes could do this much more easily post-scale
+ * with some bit arithmetic.)
*/
static LLVMValueRef
lp_build_coord_mirror(struct lp_build_sample_context *bld,
- LLVMValueRef coord)
+ LLVMValueRef coord, boolean posOnly)
{
struct lp_build_context *coord_bld = &bld->coord_bld;
- struct lp_build_context *int_coord_bld = &bld->int_coord_bld;
- LLVMValueRef fract, flr, isOdd;
-
- lp_build_ifloor_fract(coord_bld, coord, &flr, &fract);
- /* kill off NaNs */
- /* XXX: not safe without arch rounding, fract can be anything. */
- fract = lp_build_max_ext(coord_bld, fract, coord_bld->zero,
-GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN);
-
- /* isOdd = flr & 1 */
- isOdd = LLVMBuildAnd(bld->gallivm->builder, flr, int_coord_bld->one, "");
+ LLVMValueRef fract;
+ LLVMValueRef half = lp_build_const_vec(bld->gallivm, coord_bld->type, 0.5);
- /* make coord positive or negative depending on isOdd */
- /* XXX slight overkill masking out sign bit is unnecessary */
- coord = lp_build_set_sign(coord_bld, fract, isOdd);
+ /*
+* We can just use 2*(x - round(0.5*x)) to do all the mirroring,
+* it all works out. (The result is in range [-1, 1.0], negative if
+* the coord is in the "odd" section, otherwise positive.)
+*/
- /* convert isOdd to float */
- isOdd = lp_build_int_to_float(coord_bld, isOdd);
+ coord = lp_build_mul(coord_bld, coord, half);
+ fract = lp_build_round(coord_bld, coord);
+ fract = lp_build_sub(coord_bld, coord, fract);
+ coord = lp_build_add(coord_bld, fract, fract);
- /* add isOdd to coord */
- coord = lp_build_add(coord_bld, coord, isOdd);
+ if (posOnly) {
+ /*
+ * Theoretically it's not quite 100% accurate because the spec says
+ * that ultimately a scaled coord of -x.0 should map to int coord
+ * -x + 1 with mirroring, not -x (this does not matter for bilinear
+ * filtering).
+ */
+ coord = lp_build_abs(coord_bld, coord);
+ /* kill off NaNs */
+ /* XXX: not safe without arch rounding, fract can be anything. */
+ coord = lp_build_max_ext(coord_bld, coord, coord_bld->zero,
+ GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN);
+ }
return coord;
}
@@ -363,6 +371,11 @@ lp_build_sample_wrap_linear(struct lp_build_sample_context
*bld,
}
/* clamp to [0, length] */
+ /*
+ * Unlike some other wrap modes, this should be correct for gather
+ * too. GL_CLAMP explicitly does this clamp on the coord prior to
+ * actual wrapping (which is per sample).
+ */
coord = lp_build_clamp(coord_bld, coord, coord_bld->zero, length_f);
coord = lp_build_sub(coord_bld, coord, half);
@@ -426,8 +439,13 @@ lp_build_sample_wrap_linear(struct lp_build_sample_context
*bld,
offset = lp_build_int_to_float(coord_bld, offset);
coord = lp_build_add(coord_bld, coord, offset);
}
- /* was: clamp to [-0.5, length + 0.5], then sub 0.5 */
- /* can skip clamp (though might not work for very large coord values) */
+ /*
+ * We don't need any clamp. Technically, for very large (pos or neg)
+ * (or infinite) values, clamp against [-length, length] would be
+ * correct, but we don't need to guarantee any specific
+ * result for such coords (the ifloor will be undefined, but for modes
+
Re: [Mesa-dev] Gallium ARB_get_program_binary support
Hi, as always thanks for testing :) Are you able to find out which patch causes the crash? I'm curious if its the ARB_get_program_binary support or if I break the regular cache when re-factoring. Thanks, Tim On 09/12/17 15:58, Dieter Nützel wrote: Hello Tim, first time ever, that I got a real regression with your GREAT work. ;-) DiRT Rally sig fault (SIGSEGV(11) with this series. (see attachment) Bad cache hit re-read? Removing .cache/mesa_shader_cache do not help. Searching for the rigth Feral (Steam?) cache dir. - Alex/James? Then I'll have to find which of the five did it. From the log I got this: [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox() called with multiple threads in process gpu-process [1209/054157:INFO:CONSOLE(0)] "The specified value '!' does not conform to the required format. The format is '#rrggbb' where rr, gg, bb are two-digit hexadecimal numbers.", source: file://localhost/home1/alexander/My%20Games/Steam/steamapps/common/DiRT%20Rally/share/FeralUI/PGOW/Core/feralUI.html (0) Installing breakpad exception handler for appid(steam)/version(1509425745) [1209/054158:INFO:CONSOLE(0)] "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.";, source: (0) [1209/054208:WARNING:x11_util.cc(1490)] X error received: serial 4814, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow) SDL2 initialised [built against 2.0.5, running with 2.0.5] DirtRally: dumped to "/home/alexander/.local/share/feral-interactive/DiRT Rally/crashes/2363a778-c194-621f-0f837dfb-191070fd.dmp" Cheers, Dieter Am 08.12.2017 10:57, schrieb Timothy Arceri: Core support in now in master so this is just a resend of the gallium patches. Resolves crash in Dead Island: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564 Branch available here: https://github.com/tarceri/Mesa.git gallium-program-binary ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104185] CS:GO randomly locks up the entire system requiring forced reboot
https://bugs.freedesktop.org/show_bug.cgi?id=104185 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Timothy Arceri --- That bug report is for the Nvidia binary driver. Can you please report what hardware you are using. Reporting the output of 'glxinfo | grep OpenGL' should be enough. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103579] Vertex shader causes compiler to crash in SPIRV-to-NIR
https://bugs.freedesktop.org/show_bug.cgi?id=103579 Bas Nieuwenhuizen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Bas Nieuwenhuizen --- A patch that fixes compilation is in master: https://cgit.freedesktop.org/mesa/mesa/commit/?id=b926da241a4221376afe195c476f6a05621e5c75 -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104185] CS:GO randomly locks up the entire system requiring forced reboot
https://bugs.freedesktop.org/show_bug.cgi?id=104185 Bug ID: 104185 Summary: CS:GO randomly locks up the entire system requiring forced reboot Product: Mesa Version: 17.2 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: omin...@autistici.org QA Contact: mesa-dev@lists.freedesktop.org The issue being discussed on Valve's ticket system: https://github.com/ValveSoftware/csgo-osx-linux/issues/1539 kisak-valve commented on 17 Oct: "In general, no OpenGL application should be capable of deadlocking the system. If it does, then this most likely a video driver issue." I am not that experienced with trying to catch this in a log report. If anyone would offer guidance I will include diagnostics. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Gallium: Signed VBO offsets to fix SPECviewperf stability
Hello Marek, could you please rebase your gl31 branch or send these rebased patches, again? I'll do some 'real' apps testing over the Christmas days. Greetings, Dieter Am 30.10.2017 17:23, schrieb Marek Olšák: I use SPECviewperf from the phoronix test suite. See the gl31 branch in my repo. Marek On Mon, Oct 30, 2017 at 2:18 PM, Dieter Nützel wrote: Hello Marek, running with this since it appears. Which SPECviewperf version (self compiled) are you using? I've read that 'latest' versions are Windows only. Only have a _very_ old 32-bit self compiled version here, currently...;-) BTW Do have a pointer to your OpenGL 3.1 Compatibility tree handy (or new current version)? Thanks, Dieter Am 26.10.2017 17:30, schrieb Marek Olšák: Hi, This is a necessary feature to prevent out-of-memory errors with SPECviewperf for drivers relying on u_vbuf for vertex uploads. Only RadeonSI supports it at the moment. I don't think we need to change pipe_vertex_buffer::buffer_offset to int64_t just yet. Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104183] mesa-17.3.0/src/broadcom/qpu/qpu_pack.c:171]: (error) Invalid memcmp() argument
https://bugs.freedesktop.org/show_bug.cgi?id=104183 Bug ID: 104183 Summary: mesa-17.3.0/src/broadcom/qpu/qpu_pack.c:171]: (error) Invalid memcmp() argument Product: Mesa Version: 17.3 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: dcb...@hotmail.com QA Contact: mesa-dev@lists.freedesktop.org mesa-17.3.0/src/broadcom/qpu/qpu_pack.c:171]: (error) Invalid memcmp() argument nr 3. A non-boolean value is required. Source code is return (packed_sig == 0 || memcmp(sig, &v33_sig_map[0], sizeof(*sig) != 0)); Maybe better code return (packed_sig == 0 || memcmp(sig, &v33_sig_map[0], sizeof(*sig)) != 0); -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 104182] Seti@Home OpenCL program starts then returns: "CL file build failure"
https://bugs.freedesktop.org/show_bug.cgi?id=104182 Bug ID: 104182 Summary: Seti@Home OpenCL program starts then returns: "CL file build failure" Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: thinkingbeyondthesqu...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Running Messa 17.4 Podaka PPA under Ubuntu 17.10 using AMD/ATI video card (RX 480) and an AMD Ryzen 1700. (Though I'm sure its a graphics driver/system related issue, not a CPU issue) This is an OpenCL error. Seti@home, via BOINC, using proprietary AMDGPU-Pro drivers for OpenCL, works as expected so it is likely that there is either a bug, or something unfinished, in the Open Source OpenCL driver that is failing. As a side note, in 2015 this issue hit the nVidia side of things generating this issue: http://setiathome.berkeley.edu/forum_thread.php?id=77133#1665089 This might give you an idea of what may be occurring in the AMD driver side of things. I am reporting the bug to help improve the open source driver stack. Cheers :) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/{r600, radeonsi}: Fix segfault with color format (v2)
Hi! As for me, patch is too minor and be in future 18.+ release is enough, As i know application can't cause segfault by public API by this path(only by private api). On Tue, Nov 28, 2017 at 4:48 PM, Marek Olšák wrote: > On Tue, Nov 28, 2017 at 3:46 PM, Emil Velikov > wrote: > > On 28 November 2017 at 13:44, Andres Gomez wrote: > >> Denis, this looks like a good candidate to nominate for inclusion in > >> the 17.2 stable queue. > >> > >> What do you think? > >> > > Patch seems safe, but it's a bit meh since it says "segfault" without > > specifying any usecase. > > IIRC the only example is a "This only example of code, that we can use > > for check is_format_supported call. Its not real world code." > > > > If anyone can weight for/against that'll be appreciated. > > The patch is safe to apply to stable. > > Marek > -- Best regards, Denis. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium ARB_get_program_binary support
I can confirm these sort the crash on Dead Island and I can confirm I'm also seeing the segfault with Dirt Rally On Fri, 8 Dec 2017 at 09:58 Timothy Arceri wrote: > Core support in now in master so this is just a resend of the gallium > patches. > > Resolves crash in Dead Island: > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564 > > Branch available here: > > https://github.com/tarceri/Mesa.git gallium-program-binary > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
