Prevents a memory leak.
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index c2b78c6..382e116 100644
--- a/src/ga
Prevents a potential memory leak found when tracking down something else.
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 309fee4..fb9c68c 100644
--- a/src
---
src/gallium/drivers/r600/evergreen_compute.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index f0f537c..25ca5d4 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/d
Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.
Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and poss
Most of these fixes target radeon (both EG and SI), but some also help
clover, pipe loader, and also vdpau playback.
These have been tested mostly on evergreen, but I've had them running
on my desktop (pitcairn) for a few weeks as well.
Aaron Watry (8):
clover: Remove unused var
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index cf6d21e..2ace91f 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_util.c
+++ b/src/gallium/d
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3f50317..e826669 100644
--- a/src/gallium/state_trackers/clover/llvm/inv
Found while tracking down memory leaks in VDPAU playback
---
src/gallium/drivers/r600/r600_pipe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 4016bbe..74e007b 100644
--- a/src/gallium/drivers/r600/r600_pip
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 25ca5d4..e410870 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/s
Found while tracking down memory leaks in VDPAU playback
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/drivers/r600/r600_pipe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 4016bbe..74e007b 10064
Most of these fixes target radeon (both EG and SI), but some also help
generic clover and also vdpau playback.
v2: Remove an unnecessary null check in patch 4 of 8
CC: "10.0"
Aaron Watry (8):
clover: Remove unused variable
pipe_loader/sw: close dev->lib when initialization fa
v2: Remove unnecessary null pointer check
CC: "10.0"
---
src/gallium/drivers/r600/evergreen_compute.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index f0f537c..caac599 100644
--- a/src/gallium
Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.
Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and poss
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3f50317..e826669 100644
--- a/sr
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index caac599..251021c 100644
--- a/src/gallium/
Prevents a memory leak.
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
i
Prevents a potential memory leak found when tracking down something else.
Reviewed-by: Christian König
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/galliu
Reviewed-by: Tom Stellard
CC: "10.0"
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index cf6d21e..2ace91f 100644
--- a/src/gallium/drivers/radeo
CC: "10.0"
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 0fec6d5..3ed1029 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src
Note: I don't have hardware to test this, but I believe it to be correct.
Found while tracking down a related leak in evergreen context management.
---
src/mesa/drivers/dri/radeon/radeon_common_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/
CC: "10.0"
---
src/gallium/state_trackers/dri/common/dri_screen.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c
b/src/gallium/state_trackers/dri/common/dri_screen.c
index 7410dbe..a657249 100644
--- a/src/gallium/state_trackers/dri/com
tested the radeonsi patch on another machine.
Aaron Watry (4):
radeonsi: Free gfx command stream when destroying context
st/dri: prevent leak of dri option default values
r200: Free glCtx in radeonDestroyContext
mesa/main: Free ctx->DrawIndirectBuffer during teardown
src/gallium/dri
ctx->DrawIndirectBuffer wasn't being free'd in _mesa_free_buffer_objects
With this patch, "valgrind --leak-check=full glxgears" on evergreen (CEDAR)
now shows:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
On Mon, Jan 6, 2014 at 1:26 PM, Ian Romanick wrote:
> On 01/02/2014 10:38 AM, Aaron Watry wrote:
>> Note: I don't have hardware to test this, but I believe it to be correct.
>>
>> Found while tracking down a related leak in evergreen context management.
>> ---
v2: Dropped r200 patch
Moved gfx/dma cleanup to r600_common_context_cleanup
Fixed comment style in one of the patches
Aaron Watry (3):
radeon: Move gfx/dma cs cleanup to r600_common_context_cleanup
st/dri: prevent leak of dri option default values
mesa/main: Free ctx
ctx->DrawIndirectBuffer wasn't being free'd in _mesa_free_buffer_objects
With this patch, "valgrind --leak-check=full glxgears" on evergreen (CEDAR)
now shows:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
The radeonsi code was not cleaning up either of these items leading to
leaked memory.
v2: Move cleanup to r600_common_context_cleanup instead of duplicating
the logic for SI
CC: "10.0"
---
src/gallium/drivers/r600/r600_pipe.c | 7 ---
src/gallium/drivers/radeon/r600_pipe_common
v2: Change comment style
CC: "10.0"
Reviewed-by: Marek Olšák
---
src/gallium/state_trackers/dri/common/dri_screen.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c
b/src/gallium/state_trackers/dri/common/dri_screen.c
index 7410dbe..b
On Thu, Jan 9, 2014 at 3:07 PM, Carl Worth wrote:
> Hi folks,
>
> I just released Mesa 10.0.2 (a bit late) and followed it by immediately
> working through my queue of commits nominated for the stable branch,
> which I've just pushed out.
>
> Since the code for 10.0.2 was done and pushed a week ag
On Jan 10, 2014 8:47 PM, Chris Forbes wrote:
>
> Oops. Thanks for fixing this.
>
> I don't think you want this in 10.0 though -- ARB_draw_indirect only
> landed in 10.1/master.
In that case I guess back porting this to 10.0 would probably not work so well.
Thanks for the review.
--Aaron
>
A general FYI for anyone: The mesa-dev archive has a copy of the patch
that you can download.
http://lists.freedesktop.org/archives/mesa-dev/2014-January/051551.html
On Tue, Jan 14, 2014 at 3:29 PM, Dorrington, Albert
wrote:
> Hi Francisco,
>
> I'd be glad to try the patch out, unfortunately it
I'm not sure about debian's upstream packages, but at least Ubuntu's
xorg-edgers PPA has llvm-3.4 packages available and I suspect that a
variant of those will end up in the 14.04 LTS release. I've
successfully built libclc and Mesa w/ OpenCL support against those
packages after some massaging (nee
o been affected in other ways.
CC: "10.1"
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/memory.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/memory.cpp
b/src/gallium/state_trackers/clover/api/memory.cpp
inde
On Thu, Apr 3, 2014 at 6:54 PM, Francisco Jerez wrote:
> Aaron Watry writes:
>
>> This should fix a segfault in the case that you're not using ocl-icd.
>>
>> If you're using ocl-icd, make sure your version is new enough or you'll get
>> the segfault b
Yeah, that looks good to me. Several of the function headers already
mention similar validation, but it's nice to see it in plain language.
Hopefully it's not a mistake I'll make again.
--Aaron
On Fri, Apr 4, 2014 at 7:12 AM, Francisco Jerez wrote:
> Aaron Watry writ
On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
> Notice our multiple values for M_PI_2, which rounded ...32 up to
> ...4 and ...5.
> ---
> The float casts are ugly. I tried to define M_PI_2f using the
> preprocessor -- something like
>#define M_PI_2f M_PI_2##f
> but no luck.
>
> src/glsl
Fixes the build here as well (r600g+clover,radeonsi+clover). Code
changes look ok, but I'm not super-familiar with the details and I'll
let Tom's reviewed-by stand.
--Aaron
On Tue, Apr 15, 2014 at 8:49 PM, wrote:
> From: Roland Scheidegger
>
> Just adjust to the ever-changing API, pass in MCC
On Tue, Jun 3, 2014 at 8:14 AM, Jon TURNEY wrote:
> Some untangling to fix building in the dri_platform=none,
> --enable-driglx-direct
> case, where only driswast can be used.
>
> Turn the test for including the glXGetScreenDriver()/glXGetScreenDriver()
> interface used by xdriinfo from !GLX_USE_
For the series:
Tested-by: Aaron Watry
Config:
./configure --with-dri-drivers=radeon --with-gallium-drivers=r600
--enable-texture-float --enable-opencl --enable-gles1 --enable-gles2
--enable-xvmc --enable-vdpau --enable-r600-llvm-compiler
--with-egl-platforms=x11,drm --enable-glx-tls
On Thu
Hi Tom,
I'm not too qualified to review the llvm code changes, but the changes
looked sane. I did want to point out a few piglit changes/regressions as a
result of this set of patches.
For my HD6850, running latest llvm from git:
gegl-rgb-gamma-u8-to-ragabaf: pass -> fail
v3i32-stack: pass -> fai
Not sure if this helps much, but...
With gentype being one of:
char, uchar, short, ushort, int, uint, long, ulong, and the widths
being scalar, 2, 3, 4, 8, or 16 components wide.
From the OpenCL 1.1 spec:
gentype mad_hi(gentype a, gentype b):
Computes x * y and returns the high half of the produc
I know it's been pushed already, but this also fixes some lockups that
I was seeing on Barts (HD6850) when running piglit's OpenCL tests.
Thanks for fixing this.
--Aaron
On Fri, May 3, 2013 at 9:47 AM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Fri, May 3, 2013 at 4:01 PM,
This series, and the associated mesa changes are all:
Tested-By: Aaron Watry
--Aaron
On Fri, May 3, 2013 at 5:53 PM, Tom Stellard wrote:
> Hi,
>
> The attached patches modify the CodeEmitter to emit true ISA.
> Previously, we were prefixing all instructions with an instruction
These two patches fix a number of piglit OpenCL test failures on my
HD6850 (Barts).
There are no piglit CL test regressions and the llvm make check runs
without any unexpected failures.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index c6e2136..6dec4d1 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index 6dec4d1..ac56ed8 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600
These two patches fix a number of piglit OpenCL test failures on my
HD6850 (Barts).
There are no piglit CL test regressions and the llvm make check runs
without any unexpected failures.
v2: Add tests for v4i32 data type.
___
mesa-dev mailing list
mesa-
Signed-off-by: Aaron Watry
v2: Add vselect v4i32 test
---
lib/Target/R600/R600ISelLowering.cpp |3 +++
test/CodeGen/R600/vselect.ll | 17 +
2 files changed, 20 insertions(+)
create mode 100644 test/CodeGen/R600/vselect.ll
diff --git a/lib/Target/R600
Signed-off-by: Aaron Watry
v2: Add v4i32 test
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/sra.ll | 13 +
2 files changed, 15 insertions(+)
create mode 100644 test/CodeGen/R600/sra.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib
Fixes piglit test for OpenCL builtin mul24, and allows mad24 to run.
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/mul.ll | 16
2 files changed, 18 insertions(+)
create mode 100644 test/CodeGen/R600/mul.ll
diff
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
test/CodeGen/R600/sub.ll | 15 +++
2 files changed, 17 insertions(+)
create mode 100644 test/CodeGen/R600/sub.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600
On Fri, May 17, 2013 at 2:31 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Fri, May 17, 2013 at 7:44 AM, Jose Fonseca wrote:
>> > Vinson,
>> >
>> > Why is this necessary?
>> >
>> > (I'd prefer that LLVM is statically linked by default. )
>> >
>> > Jose
>>
>> The SCons build fai
Reviewed-by: Aaron Watry
Please also send the attached test patch (or an expanded version of
it) to the piglit list.
On Thu, May 23, 2013 at 12:48 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> generic/include/clc/clc.h | 1 +
> generic/include
I've implemented the OpenCL vload/vstore builtin functions in two parts.
1) Pure CL C implementation. No Assembly
2) Add assembly optimizations for 32-bit int/uint loads/stores of 4+ component
vectors
Note: The vstore implementation assumes that the hardware back end supports
byte-addressable s
Should work for all targets and data types. Completely unoptimized.
---
generic/include/clc/clc.h | 1 +
generic/include/clc/shared/vload.h | 37 ++
generic/lib/SOURCES| 1 +
generic/lib/shared/vload.cl| 47 +++
Assumes that the target supports byte-addressable stores.
Completely unoptimized.
---
generic/include/clc/clc.h | 1 +
generic/include/clc/shared/vstore.h | 36
generic/lib/SOURCES | 1 +
generic/lib/shared/vstore.cl| 56 +++
The assembly should be generic, but at least currently R600 only supports
32-bit loads of int1/4, and I believe that only global is well-supported.
R600 lowers the 8/16 component vectors to multiple 4-bit loads.
The unoptimized C versions of the other stuff is left in place.
---
generic/lib/SOUR
The assembly should be generic, but at least currently R600 only supports
32-bit stores of [u]int1/4, and I believe that only global is well-supported.
R600 lowers the 8/16 component stores to multiple 4-component stores.
The unoptimized C versions of the other stuff is left in place.
---
generi
Looks good to me. Is there a piglit test for this?
--Aaron
On Wed, Jun 5, 2013 at 7:12 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover
ng is there and functioning.
For the libclc change:
Reviewed-by: Aaron Watry
On Wed, Jun 12, 2013 at 7:31 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> r600/lib/SOURCES | 2 ++
> r600/lib/synchronization/barrier.cl | 15 +++
> r
On Wed, Jun 12, 2013 at 7:34 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 23 +++-
> src/gallium/drivers/r600/r600_shader.c | 32
>
> 2 files changed, 22 insertions(+), 33 deletions(-)
>
ed-by: Aaron Watry
On Wed, Jun 12, 2013 at 7:34 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> And allocate the correct amount before dispatching the kernel.
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 53
> +++---
> .../drivers/r600/ev
Also add a seperate vector lit test file, since r600 doesn't seem to handle
v2i32 load/store yet, but we can test both for SI.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIInstructions.td | 5 +
test/CodeGen/R600/load.vec.ll | 19 +++
2 files changed, 24 inser
First patch fixes load/store for v2i32 on R600. Without this, the
other two will cause make check failures. I've verified the changes
using a Radeon 5400 (Cedar). Note that the previous custom
lowering of v2i32 store was causing silent data corruption.
The other two patches expand add/sub on SI
The custom lowering causes llc to crash with a segfault.
Ideally, the custom lowering can be fixed, but this allows
programs which load/store v2i32 to work without crashing.
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp | 4 ++--
test/CodeGen/R600/load.vec.ll| 6
Also add SI tests to existing file and a v2i32 test for both
R600 and SI.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 2 ++
test/CodeGen/R600/add.ll | 37 +++--
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/lib
ion order.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/sub.ll | 37 +++--
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/lib/Target/R600/SIISelLowering.cpp
b/lib/Target/R600/SIISelLowering.c
Tested on Pitcairn by: Aaron Watry
Follow-up question: Would it be as easy as it looks to add v2i32 right away?
On Tue, Jun 18, 2013 at 6:21 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> lib/Target/R600/AMDGPUCallingConv.td| 9 +
> test/CodeGen/R60
tores.
--Aaron
On Thu, Jun 20, 2013 at 4:30 PM, Tom Stellard wrote:
> On Wed, Jun 19, 2013 at 08:51:01AM -0700, Tom Stellard wrote:
>> On Mon, Jun 17, 2013 at 04:11:38PM -0500, Aaron Watry wrote:
>> > The custom lowering causes llc to crash with a segfault.
>> >
>> >
xpand) calls that appear in
both R600ISelLowering.cpp and SIISelLowering.cpp are all moved to
AMDGPUISelLowering.cpp. If we decide to implement these ops through native
instructions for either target in the future, we can override that in the
individual targets.
Signed-off-by: Aaron Watry
R600/SI: E
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/and.ll | 37 +++--
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/lib/Target
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/mul.ll | 38 --
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/lib/Target
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/or.ll| 41 +++---
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/lib/Target
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/shl.ll | 47 ++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/lib
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 2 ++
test/CodeGen/R600/srl.ll | 42 +++---
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/lib/Target
Also add lit test for both cases on SI, and v2i32 for evergreen.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 2 ++
test/CodeGen/R600/sra.ll | 41 +++---
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/lib/Target
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UDIV produces really
complex code, so let's just check that the instruction was lowered
successfully.
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UREM produces really
complex code, so let's just check that the instruction was lowered
successfully.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp
No test/expansion for SI has been added yet. Attempts to expand this
operation for SI resulted in a stacktrace in (IIRC) LegalizeIntegerTypes
which was complaining about vector comparisons being required to return
a vector type.
Signed-off-by: Aaron Watry
---
test/CodeGen/R600/setcc.ll | 25
Add test cases for both vector sizes on SI and also add v2i32 test for EG.
Signed-off-by: Aaron Watry
---
lib/Target/R600/SIISelLowering.cpp | 3 +++
test/CodeGen/R600/xor.ll | 40 +++---
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a
() == N->getOperand(0).getValueType().isVector() &&
"Vector compare must return a vector result!"' failed.
Signed-off-by: Aaron Watry
---
test/CodeGen/R600/vselect.ll | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/test/Code
By default, we expand these operations for both EG and SI. Move the
duplicated code into a common space for now. If the targets ever actually
implement these operations as instructions, we can override that in the relevant
target.
Signed-off-by: Aaron Watry
---
lib/Target/R600
Add some constant load v2i32/v4i32 tests for both EG and SI.
Tested on: Pitcairn (7850) and Cedar (54xx)
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600Instructions.td | 3 +++
lib/Target/R600/SIInstructions.td | 10 ++
test/CodeGen/R600/load.vec.ll | 27
I moved it to the top of the file, if that's ok... although I guess I
could leave it at the bottom if you want..
--Aaron
On Fri, Jun 21, 2013 at 9:05 PM, Tom Stellard wrote:
> On Thu, Jun 20, 2013 at 06:43:42PM -0500, Aaron Watry wrote:
>> Also add lit test for both cases on SI,
Tested-By: Aaron Watry
Tested on an A6-3500 (SUMO)
On Tue, Jun 18, 2013 at 11:54 AM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> lib/Target/R600/R600Instructions.td | 9 +
> test/CodeGen/R600/load.ll | 1 +
> 2 files changed, 10 insertions(+)
&g
PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
haven't done the research to find out how far back.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/ga
Disregard this patch... Looks like Tom already pushed a fix last night.
--Aaron
On Fri, Jun 28, 2013 at 9:41 AM, Aaron Watry wrote:
> PathV1.h has been removed. In theory this can go back before llvm 3.4, but I
> haven't done the research to find out how far back.
>
> Signed-of
On Tue, Feb 4, 2014 at 10:28 AM, Armin K. wrote:
> On 02/04/2014 05:24 PM, Krzysztof A. Sobiecki wrote:
>> A small patch to work around a llvm-config-3.5 change, with a newline
>> hack.
>>
>
> This would be easier to fix in LLVM. The newline is rather unnecessary
> in the output.
>
I fully agree.
Yup, that's the same exact patch that I sent to the LLVM list. It's
been working just fine along with the mesa patch in:
https://bugs.freedesktop.org/attachment.cgi?id=91764
I've been using that on my own system for a while now. It could
probably use more eyes/testing, but it seems ok from my us
ue to changes in
the LLVM versions installed on the system (as opposed to a functioning
statically linked radeonsi and egl), but I'm not sure how big an issue
that really is in practice.
Tested-by: Aaron Watry
[1] https://bugs.freedesktop.org/show_bug.cgi?id=70410
On Tue, Feb 4, 2014 at 1:2
Hi Tom,
This definitely fixes some issues that I've been seeing with int8/16
vload8() and vload16() in CL. vstore8/vstore16 are still broken, but
at least the loads are working now (I've only tested int, but I can
give a full test run if you want/need).
For reference, the tests that failed befor
Fix a leaked vertex shader in u_blitter.c
Signed-off-by: Aaron Watry
CC: "10.1"
---
src/gallium/auxiliary/util/u_blitter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 95e7fb6..66b511e 10
Free shader buffer object for all kernels when deleting compute state.
Signed-off-by: Aaron Watry
---
src/gallium/drivers/radeonsi/si_compute.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index
>
> Do people have opinions on whether it'd be useful to also gather data
> for older hardware? FWIW I threw my TNT2 in there, which is probably
> among the oldest hw supported by mesa.
>
I'm not sure if it's worthwhile or not, but if you want/need it, I've
got a Radeon x1950 at home that I can po
On Fri, Mar 28, 2014 at 10:32 AM, Ilia Mirkin wrote:
> On Fri, Mar 28, 2014 at 11:14 AM, Aaron Watry wrote:
>>>
>>> Do people have opinions on whether it'd be useful to also gather data
>>> for older hardware? FWIW I threw my TNT2 in there, which is probably
&
I like it, but one thing I'd like to request... Can you check to make
sure that radeon_shader_binary.global_symbol_offsets isn't also
leaked? If so, let's fix that as well.
If that's not getting leaked, then it looks good to me.
--Aaron
On Mon, Dec 1, 2014 at 5:33 PM, Jan Vesely wrote:
> ping
>
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index cda447d..5265d10 100644
--- a/src
On Mon, Sep 7, 2015 at 4:06 AM, Emil Velikov
wrote:
> Hi Jon,
>
> On 4 September 2015 at 14:00, Jon TURNEY
> wrote:
> > When checking for LLVM shared libraries, use IMP_LIB_EXT for the
> extension for
> > shared libraries appropriate to the target, rather than hardcoding '.so'
> >
> > Also add s
Fixes make check.
CC: Jason Ekstrand
Signed-off-by: Aaron Watry
---
src/glsl/nir/tests/control_flow_tests.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/glsl/nir/tests/control_flow_tests.cpp
b/src/glsl/nir/tests/control_flow_tests.cpp
index b9f90e6..f142e44
Hi Marek,
This patch ended up breaking make check for me (src/egl/egl-symbols-check).
Also, while bisecting, it occurred to me that you pushed v2 of the series,
while you had previously sent a v3 to the mesa-dev list. Was pushing v2
intentional?
--Aaron
On Tue, Mar 8, 2016 at 4:52 PM, Marek Olš
101 - 200 of 392 matches
Mail list logo
