I've been building git llvm and mesa on a RHEL7 tinderbox (tinderbox.x.org)
This just appeared.
Dave.
gallivm/lp_bld_debug.cpp: In function 'size_t disassemble(const void*,
llvm::raw_ostream)':
gallivm/lp_bld_debug.cpp:283:23: error: cannot declare variable
'memoryObject' to be of abstract type
According to the documentation, we need to do a CS stall on every fourth
PIPE_CONTROL command to avoid GPU hangs. The kernel does a CS stall
between batches, so we only need to count the PIPE_CONTROLs in our batches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
On Tue, Nov 11, 2014 at 11:13:28AM -0800, Kenneth Graunke wrote:
On Tuesday, November 11, 2014 06:59:51 PM Neil Roberts wrote:
Kenneth Graunke kenn...@whitecape.org writes:
drm-intel-next must have the new software checker turned on, which
disallows non-whitelisted register writes
On Wed, Nov 12, 2014 at 01:33:01AM -0800, Kenneth Graunke wrote:
According to the documentation, we need to do a CS stall on every fourth
PIPE_CONTROL command to avoid GPU hangs. The kernel does a CS stall
between batches, so we only need to count the PIPE_CONTROLs in our batches.
On Wed, Nov 12, 2014 at 11:39:28AM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 01:33:01AM -0800, Kenneth Graunke wrote:
+/* Implement the WaCsStallAtEveryFourthPipecontrol workaround on IVB, BYT:
+ *
+ * Every 4th PIPE_CONTROL command, not counting the PIPE_CONTROL with
+ * only
Thanks for the heads up.
Fixed now.
Jose
From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Dave
Airlie airl...@gmail.com
Sent: 12 November 2014 08:05
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] build regression in tinderbox
clCreateContext no longer crash when CL_CONTEXT_PLATFORM is invalid
---
src/gallium/state_trackers/clover/api/context.cpp | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/context.cpp
On 11/12/2014 10:39 AM, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 01:33:01AM -0800, Kenneth Graunke wrote:
According to the documentation, we need to do a CS stall on every fourth
PIPE_CONTROL command to avoid GPU hangs. The kernel does a CS stall
between batches, so we only need to count
On 11/12/2014 10:53 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 11:39:28AM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 01:33:01AM -0800, Kenneth Graunke wrote:
+/* Implement the WaCsStallAtEveryFourthPipecontrol workaround on IVB, BYT:
+ *
+ * Every 4th PIPE_CONTROL command, not
Jose Fonseca wrote:
Thanks for the heads up.
Fixed now.
clover fails for me with current llvm git + mesa head on your fix.
Making all in state_trackers/clover
make[3]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/state_trackers/clover'
CXX
From: José Fonseca jfons...@vmware.com
The latest version of the specs explicitly allow it, and given that Mesa
universally supports KHR_debug we should definitely support it.
Totally untested. (Just happened to noticed this while implementing
GLX_EXT_create_context_es2_profile for st/xlib.)
From: José Fonseca jfons...@vmware.com
apitrace now supports it, and it makes it much easier to test
tracing/replaying on OpenGL ES contexts since
GLX_EXT_create_context_{es2,es}_profile are widely available.
---
src/gallium/state_trackers/glx/xlib/glx_api.c | 5 +-
From: José Fonseca jfons...@vmware.com
The latest version of GLX_EXT_create_context_es2_profile states:
If the version requested is a valid and supported OpenGL-ES version,
and the GLX_CONTEXT_ES_PROFILE_BIT_EXT bit is set in the
GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the
Sorry, but I'm not familiar with that code base -- I don't even have a proper
environment to build it --, and this build failure is unrelated to my earlier
fix.
So I'm afraid the clover maintainers will need to step up here.
Jose
From: Andy Furniss
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg da...@ixit.cz wrote:
v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/auxiliary/util/u_dump.h | 6 ++
src/gallium/auxiliary/util/u_dump_defines.c
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/pixeltransfer.c | 62 ++-
1 file changed, 43 insertions(+), 19 deletions(-)
diff --git a/src/mesa/main/pixeltransfer.c b/src/mesa/main/pixeltransfer.c
index 8bbeeb8..273a9ac
I tested this with uploading 1024x1024 656 textures in a loop for 10 seconds.
With glTexImage2D on SNB I get 17% better performance, mobile IVB
(interestingly only) 0..1% better performance and BDW 3% better performance.
For all these tests Mesa was compiled with -O2 -march=native and no Piglit
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138 ++
src/mesa/main/sse2_clamping.h | 49 +++
3 files changed, 195 insertions(+)
create mode 100644
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index fc7d372..a01e605 100644
--- a/configure.ac
+++ b/configure.ac
@@ -258,6 +258,13 @@ if test x$SSE41_SUPPORTED = x1; then
fi
https://bugs.freedesktop.org/show_bug.cgi?id=86195
Bug ID: 86195
Summary: Lightswork video editor segfaults
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: All
Status: NEW
Severity: minor
EdB edb+m...@sigluy.net writes:
clCreateContext no longer crash when CL_CONTEXT_PLATFORM is invalid
NAK. That piglit test is rather dubious, can we please get rid of it?
Passing pointers to inaccessible memory is likely to cause a segfault on
other implementations too, like nVidia's, Intel's
Series LGTM. Reviewed-by: Brian Paul bri...@vmware.com
On 11/12/2014 05:37 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
The latest version of GLX_EXT_create_context_es2_profile states:
If the version requested is a valid and supported OpenGL-ES version,
and
On 11/12/2014 05:50 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138 ++
src/mesa/main/sse2_clamping.h | 49 +++
On 11/12/2014 05:48 AM, Erik Faye-Lund wrote:
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg da...@ixit.cz wrote:
v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/auxiliary/util/u_dump.h | 6 ++
Ping, how about this guy?
On Mon, Oct 27, 2014 at 7:36 PM, Alexandre Courbot acour...@nvidia.com wrote:
This member is declared, allocated and destroyed, but doesn't seem to be
used or referenced anywhere in the code.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Resending after
David,
__declspec(thread) on DLLs is not supported on XP. This must not go in or Mesa
DLL's won't load correctly on XP.
This is why there is no abstraction for compiler TLS. It's not very portable
yet. So I rather we didn't use a at all.
TLS is not enough to make this code safe neither.
On 12/11/14 12:37, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
The latest version of GLX_EXT_create_context_es2_profile states:
If the version requested is a valid and supported OpenGL-ES version,
and the GLX_CONTEXT_ES_PROFILE_BIT_EXT bit is set in the
Thanks for the review.
Yet the spec seems to lack any version update, or a note in the revision
history afaict :(
I don't know if Khronos did further changes but I believe there is some mention
on the bottom
https://www.opengl.org/registry/specs/EXT/glx_create_context_es2_profile.txt
where
On Wed, 2014-11-12 at 14:50 +0200, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138
++
src/mesa/main/sse2_clamping.h | 49
Hi,
On 12 November 2014 12:37, jfons...@vmware.com wrote:
@@ -544,9 +544,22 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
case GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
*api = __DRI_API_OPENGL;
break;
- case
On Wednesday, November 12, 2014 11:28:15 AM Daniel Vetter wrote:
On Tue, Nov 11, 2014 at 11:13:28AM -0800, Kenneth Graunke wrote:
On Tuesday, November 11, 2014 06:59:51 PM Neil Roberts wrote:
Kenneth Graunke kenn...@whitecape.org writes:
drm-intel-next must have the new software
Le jeudi 6 novembre 2014, 09:45:40 Tom Stellard a écrit :
On Thu, Nov 06, 2014 at 11:46:41AM -0500, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
I've pushed this, thanks!
-Tom
http://llvm.org/viewvc/llvm-project?view=revisionrevision=221711
Bad luck, it's reverted,
On Wed, Nov 12, 2014 at 07:36:04PM +0100, Laurent Carlier wrote:
Le jeudi 6 novembre 2014, 09:45:40 Tom Stellard a écrit :
On Thu, Nov 06, 2014 at 11:46:41AM -0500, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
I've pushed this, thanks!
-Tom
On 12.11.2014 18:08, Brian Paul wrote:
On 11/12/2014 05:50 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138
++
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 --
src/mesa/drivers/dri/i965/brw_fs.h | 1 -
2 files changed, 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 39c6231..7003691 100644
---
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 --
src/mesa/drivers/dri/i965/brw_fs.h | 1 -
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
---
src/mesa/drivers/dri/i965/brw_fs.h | 12
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 1c14d13..8ca5490
The visitor emits MOVs to temporary registers for immediates, so these
never trigger. For further proof, check case ir_triop_fma.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
On Wednesday, November 12, 2014 10:53:29 AM Chris Wilson wrote:
On Wed, Nov 12, 2014 at 11:39:28AM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 01:33:01AM -0800, Kenneth Graunke wrote:
+/* Implement the WaCsStallAtEveryFourthPipecontrol workaround on IVB,
BYT:
+ *
+ * Every 4th
According to the documentation, we need to do a CS stall on every fourth
PIPE_CONTROL command to avoid GPU hangs. The kernel does a CS stall
between batches, so we only need to count the PIPE_CONTROLs in our batches.
v2: Get the generation check right (caught by Chris Wilson),
combine the ++
See 546d6c8d for the corresponding fix in freedreno.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/gallium/drivers/i915/i915_screen.c | 3 +++
1 file changed, 3 insertions(+)
Not Piglit tested yet, sorry.
diff --git a/src/gallium/drivers/i915/i915_screen.c
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #4 from Sinclair Yeh s...@vmware.com ---
Thanks. I can now reproduce this issue with MESA 8.0.4 and MESA 9.0. This
seems to work fine with MESA 10.1.3.
I'll track down the root cause of this.
Do you see this vmw_ioctl_command
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #5 from Nicholas Yue yue.nicho...@gmail.com ---
(In reply to Sinclair Yeh from comment #4)
Thanks. I can now reproduce this issue with MESA 8.0.4 and MESA 9.0. This
seems to work fine with MESA 10.1.3.
I'll track down the root
texture_offset was only used by some texturing operations, and offset
was only used by spill/unspill and some URB operations. These fields are
never used at the same time.
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 6 +++---
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 --
src/mesa/drivers/dri/i965/brw_shader.h | 2 ++
src/mesa/drivers/dri/i965/brw_vec4.h | 3 ---
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index
On 12.11.2014 19:36, Bruno Jimenez wrote:
On Wed, 2014-11-12 at 14:50 +0200, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138
These too are
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Wed, Nov 12, 2014 at 11:28 AM, Matt Turner matts...@gmail.com wrote:
texture_offset was only used by some texturing operations, and offset
was only used by spill/unspill and some URB operations. These fields are
never used
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On 2014-11-12 11:20:46, Kenneth Graunke wrote:
See 546d6c8d for the corresponding fix in freedreno.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/gallium/drivers/i915/i915_screen.c | 3 +++
1 file changed, 3 insertions(+)
On 01/11/14 04:08, Emil Velikov wrote:
On 22/10/14 22:14, Emil Velikov wrote:
Hi all,
I was wondering earlier how far are we until the 10.4 release and it
hit me... there isn't much left. So in order to stick with the original
three month release schedule here is my proposal.
November 14th
Okay,
| glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #6 from Emil Velikov emil.l.veli...@gmail.com ---
(In reply to Sinclair Yeh from comment #4)
Do you see this vmw_ioctl_command error Invalid argument. in the terminal
when you run mplay-bin?
Those messages happen when a mix of
On Wednesday, November 12, 2014 10:09:00 PM Steven Stewart-Gallus wrote:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Bay Trail
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
You're using the classic Intel driver
This switch statement's code structure isn't dependent on the numbers of
the opcodes at all.
---
src/gallium/drivers/r300/r300_tgsi_to_rc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
index
The nice thing about the good way of initializing arrays like this is that
you don't need to initialize everything in order, or even everything at
all. Taking advantage of that only needs a tiny fixup to deal with the
default NULL value of the pointers.
I haven't dropped the initialization of
This series removes a bunch of unused opcodes, mostly from TGSI. It
doesn't go as far as we could possibly go -- while I welcome discussion
for future patch series deleting more, I hope that discussion doesn't
derail the review process for these changes.
I haven't messed with the subroutine
Neither was generated anywhere in the tree. Given that address registers
don't really map as a concept to most hardware these days, we're probably
unlikely to ever extend in the direction of using more address register
opcodes.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c| 1 -
They weren't generated in tree, and as far as I know all hardware had to
lower it to a DP, RSQ, MUL.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 5 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 95 -
src/gallium/auxiliary/tgsi/tgsi_exec.c | 72
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 3 --
src/gallium/auxiliary/tgsi/tgsi_exec.c | 56
src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +-
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 -
src/gallium/docs/source/tgsi.rst
They're part of NV_vertex_program2, which I'm pretty sure we're never
going to support.
---
src/mesa/program/prog_execute.c | 12
src/mesa/program/prog_instruction.c | 2 --
src/mesa/program/prog_instruction.h | 2 --
3 files changed, 16 deletions(-)
diff --git
The extension itself was deleted 2 years ago. There are still some
prog_instruction opcodes from NV_fp that exist because they're used by
ir_to_mesa.cpp, though.
---
src/mesa/program/prog_execute.c | 144
src/mesa/program/prog_instruction.c | 10 ---
These are obviously the gaps already, due to the bare numbers with
unsupported implementations.
This makes inserting new gaps less irritating.
---
src/gallium/drivers/r600/r600_shader.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
Nothing in the tree generates it.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 1 -
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 6
src/gallium/auxiliary/tgsi/tgsi_exec.c | 45 -
src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +-
Nothing in the tree generated it.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 19 ---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c| 9 -
src/gallium/auxiliary/tgsi/tgsi_exec.c | 16
src/gallium/auxiliary/tgsi/tgsi_info.c
Never generated, and implemented in only nvfx vertprog.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 1 -
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 6 --
src/gallium/auxiliary/tgsi/tgsi_exec.c | 4
src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +-
Nothing in the tree generated it.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 1 -
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c | 5 -
src/gallium/auxiliary/tgsi/tgsi_exec.c | 20
src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +-
AFAIK at least some of these (NRM, ARR, probably others) were being used by
the d3d9 state tracker. Not sure what its status is, but I believe the hope
was to eventually get it into the tree.
On Wed, Nov 12, 2014 at 8:18 PM, Eric Anholt e...@anholt.net wrote:
This series removes a bunch of
Ilia Mirkin imir...@alum.mit.edu writes:
AFAIK at least some of these (NRM, ARR, probably others) were being used by
the d3d9 state tracker. Not sure what its status is, but I believe the hope
was to eventually get it into the tree.
They've got code for lowering NRM and CND to sanity, and no
On Fri, Nov 07, 2014 at 04:52:25PM +, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Hi Jose,
This patch is causing random segfaults with OpenCL programs on radeonsi.
I haven't been able to figure out exactly what is happening, so I was
hoping you could help.
I think
Every other unit in the geometry pipeline automatically enables
statistics gathering. This part of the pipe has been controlled by the
DEBUG_STATS variable, but this is asymmetric. This dates back to the
original implementation, and I am not sure if there is a reason for it.
I need access to
https://bugs.freedesktop.org/show_bug.cgi?id=86195
--- Comment #1 from Michel Dänzer mic...@daenzer.net ---
Please run the app with the environment variable R600_DEBUG=vs, capture its
stderr output to a file and attach that file here after the crash.
BTW, does setting the environment variable
On Wednesday, November 12, 2014 06:54:31 PM Ben Widawsky wrote:
Every other unit in the geometry pipeline automatically enables
statistics gathering. This part of the pipe has been controlled by the
DEBUG_STATS variable, but this is asymmetric. This dates back to the
original implementation,
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 18 --
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 11 ++-
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
We did this for fs_reg a while back, and it's generally a good idea.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 6 +--
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 35 ---
We do this almost everywhere else; this should make it easier to modify.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 98 +++-
1 file changed, 41 insertions(+), 57 deletions(-)
diff --git
17 insertions(+), 102 deletions(-). Works just as well.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4.h | 8 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 111 -
2 files changed, 17 insertions(+), 102
On Wed, Nov 12, 2014 at 9:35 PM, Kenneth Graunke kenn...@whitecape.org wrote:
+vec4_visitor::emit_math(enum opcode opcode,
+ dst_reg dst, src_reg src0, src_reg src1)
I think you can make the arguments const references too?
+ if (brw-gen == 6 dst.writemask !=
From: Michel Dänzer michel.daen...@amd.com
Using the asynchronous DMA engine for multi-dimensional operations seems
to cause random GPU lockups for various people. While the root cause for
this might need to be fixed in the kernel, let's disable it for now.
Before re-enabling this, please make
77 matches
Mail list logo
