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
---
src/mesa/drivers/dri/i965/brw_context.h
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 writes:
> >
> > > drm-intel-next must have the new software checker turned on, which
> > > disallows non-whitelisted register writes (along with lib
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.
>
> Signe
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
> > +
Thanks for the heads up.
Fixed now.
Jose
From: mesa-dev on behalf of Dave
Airlie
Sent: 12 November 2014 08:05
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] build regression in tinderbox
I've been building git llvm and mesa on a RHEL7 tinderbo
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
b/src/gallium/state_trackers/clover/api/conte
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
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 co
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 llvm/libclllvm_la-invocatio
From: José Fonseca
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.)
---
src/gallium/state
From: José Fonseca
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 +-
src/gallium/state_trackers/glx/xlib/xm_api.c |
From: José Fonseca
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 context
returned
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
Sen
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg wrote:
> v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/auxiliary/util/u_dump.h | 6 ++
> src/gallium/auxiliary/util/u_dump_defines.c | 86
> +
Signed-off-by: Juha-Pekka Heikkila
---
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 100644
--- a/src/mesa/main/pi
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
reg
Signed-off-by: Juha-Pekka Heikkila
---
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 src/mesa/main/sse2_clamping.c
Signed-off-by: Juha-Pekka Heikkila
---
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
AM_CONDITIONAL([SSE41_SUP
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
On Tue, Nov 4, 2014 at 1:05 PM, Juha-Pekka Heikkila
wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/main/pixeltransfer.c | 62
> ++-
> 1 file changed, 43 insertions(+), 19 deletions(-)
>
> diff --git a/src/mesa/main/pixeltransfer.c b/src/mesa
EdB 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 or any implementati
Series LGTM. Reviewed-by: Brian Paul
On 11/12/2014 05:37 AM, jfons...@vmware.com wrote:
From: José Fonseca
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
On 11/12/2014 05:50 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/Makefile.am | 8 +++
src/mesa/main/sse2_clamping.c | 138 ++
src/mesa/main/sse2_clamping.h | 49 +++
3 files changed, 195 insert
On 11/12/2014 05:48 AM, Erik Faye-Lund wrote:
On Sun, Nov 2, 2014 at 7:32 PM, David Heidelberg wrote:
v2: rename and extend support with code for C11 and MSVC (thanks to Brian)
Signed-off-by: David Heidelberg
---
src/gallium/auxiliary/util/u_dump.h | 6 ++
src/gallium/auxiliary/ut
Ping, how about this guy?
On Mon, Oct 27, 2014 at 7:36 PM, Alexandre Courbot 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
> ---
> Resending after fixing typo in email address - ap
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. Th
On 12/11/14 12:37, jfons...@vmware.com wrote:
> From: José Fonseca
>
> 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
for the moment clang doesn't support this optimization hint
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3a4fcf
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 i
On Wed, 2014-11-12 at 14:50 +0200, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/Makefile.am | 8 +++
> src/mesa/main/sse2_clamping.c | 138
> ++
> src/mesa/main/sse2_clamping.h | 49 +++
> 3 files
Hi,
On 12 November 2014 12:37, 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 GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
> -
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 writes:
> > >
> > > > drm-intel-next must have the new software checker turne
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
>
> I've pushed this, thanks!
>
> -Tom
http://llvm.org/viewvc/llvm-project?view=revision&revision=221711
Bad luck, it's reverted, so now:
CXX
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
> >
> > I've pushed this, thanks!
> >
> > -Tom
>
> http://llvm.org/viewvc/
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
>> ---
>> src/mesa/Makefile.am | 8 +++
>> src/mesa/main/sse2_clamping.c | 138
>> ++
>> src/mesa/main/sse2_clamp
---
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
--- a/src/mesa/drivers/dri/i965/brw_fs.cp
---
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
b/src/mesa/drivers/dri/i965/brw_
---
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 1
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
b
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:
> > > + *
> > > +
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
---
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
b/src/gallium/drivers/i915/i915_screen.c
in
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #4 from Sinclair Yeh ---
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 error Invalid argum
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #5 from Nicholas Yue ---
(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 cause of this.
>
>
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/
---
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 d9150c3..6
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
>> ---
>> src/mesa/Makefile.am | 8 +++
>> src/mesa/main/sse2_clamping.c | 138
>> ++
>> src/mesa/mai
These too are
Reviewed-by: Jason Ekstrand
On Wed, Nov 12, 2014 at 11:28 AM, Matt Turner 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 at the same time.
> ---
> src/mesa/driv
Reviewed-by: Jordan Justen
On 2014-11-12 11:20:46, Kenneth Graunke wrote:
> See 546d6c8d for the corresponding fix in freedreno.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/gallium/drivers/i915/i915_screen.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Not Piglit tested yet, sorry.
>
>
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.
>>
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,
GLX_
https://bugs.freedesktop.org/show_bug.cgi?id=86070
--- Comment #6 from Emil Velikov ---
(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 downstream & upstream mod
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 (i9
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 4448f88..
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 opc
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 stuff
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 -
src/ga
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 a/src/mesa/progr
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 ---
src/
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 +-
src/gall
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
Nothing generated them.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 24 ---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c| 8
src/gallium/auxiliary/tgsi/tgsi_exec.c | 47 --
src/gallium/auxiliary/tgsi/tgsi_info.c | 4 +-
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 +-
src/g
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 +-
src/gallium/
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 wrote:
> This series removes a bunch of unused opcodes, mos
Ilia Mirkin 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 use of ARR,
ARA, X
On Fri, Nov 07, 2014 at 04:52:25PM +, jfons...@vmware.com wrote:
> From: José Fonseca
>
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 the problem has som
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 these
https://bugs.freedesktop.org/show_bug.cgi?id=86195
--- Comment #1 from Michel Dänzer ---
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 DRAW_USE_LLVM=0 avoid
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
---
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
b/src/mesa/drivers/dri
We did this for fs_reg a while back, and it's generally a good idea.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 6 +--
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 35 ---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 12 ++---
We do this almost everywhere else; this should make it easier to modify.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 98 +++-
1 file changed, 41 insertions(+), 57 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/
17 insertions(+), 102 deletions(-). Works just as well.
Signed-off-by: Kenneth Graunke
---
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 deletions(-)
diff --git a/s
On Wed, Nov 12, 2014 at 9:35 PM, Kenneth Graunke 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 != WRITEMASK_XYZW) {
> +
From: Michel Dänzer
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 sure you can hit all new
80 matches
Mail list logo
