On Fri, Jun 13, 2014 at 10:35:33PM +0200, Bruno Jiménez wrote:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 140
+++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 87 insertions
(from the item we have
just added to the pool) without problems.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600
On Fri, Jun 13, 2014 at 10:35:35PM +0200, Bruno Jiménez wrote:
This function will be used when we want to map an item
that it's already in the pool.
---
src/gallium/drivers/r600/compute_memory_pool.c | 45
++
src/gallium/drivers/r600/compute_memory_pool.h | 3 ++
On Fri, Jun 13, 2014 at 10:35:36PM +0200, Bruno Jiménez wrote:
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
1 file
On Fri, Jun 13, 2014 at 10:35:37PM +0200, Bruno Jiménez wrote:
---
src/gallium/drivers/r600/compute_memory_pool.c | 158
-
1 file changed, 78 insertions(+), 80 deletions(-)
There are double linked list helper functions in gallium util, which we
should use rather
On Fri, Jun 13, 2014 at 10:35:38PM +0200, Bruno Jiménez wrote:
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
All fields of the MIMG opcodes are exposed and can be set by Mesa,
even DMASK. All GATHER4 variants are added and there are a lot of
On Thu, Jun 12, 2014 at 02:11:11AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
LGTM.
---
test/CodeGen/R600/llvm.SI.gather4.ll | 508
+++
1 file changed, 508 insertions(+)
create mode 100644 test/CodeGen/R600/llvm.SI.gather4.ll
Some apps will abort if they detect 0 compute units. This fixes
crashes in some OpenCV tests.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
We were serializing the binaries once when clGetProgramInfo was called
with CL_PROGRAM_BINARY_SIZES and then again when it was called with
CL_PROGRAM_BINARIES. This was slowing down some OpenCV tests which were
building binary kernel caches.
This improves the run-time of OpenCV's
On Wed, Jun 11, 2014 at 05:28:01PM +0200, Bruno Jiménez wrote:
That commit made possible that the items could be one just
after the other when their size was a multiple of ITEM_ALIGNMENT.
But compute_memory_prealloc_chunk still looked to leave a gap
between items. Resulting in that we got an
On Fri, May 30, 2014 at 05:31:09PM +0200, Bruno Jiménez wrote:
This series allows clover to answer the query for the number of
max compute units of the devices.
The data has been extracted from:
AMD Accelerated Parallel Processing OpenCL Programming Guide (rev 2.7)
Appendix D: Device
On Tue, Jun 10, 2014 at 02:57:41PM +0100, Emil Velikov wrote:
On 10/06/14 03:25, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
LLVM is enabled by default for some architectures, but the test was failing
before that.
Thanks for fixing my silly mistake Michel. Would
On Tue, Jun 10, 2014 at 12:57:31AM +0200, thomashellan...@gmail.com wrote:
From: Thomas Helland thomashellan...@gmail.com
For the series:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Do these patches make any measurable improvement in compile time?
-Tom
This series removes some unused
On Sat, Jun 07, 2014 at 01:24:39PM -0700, Greg Fischer wrote:
LunarG, with support from Valve, announces the GlassyMesa project, an
effort to bring the LLVM compiler infrastructure to Mesa.
This is very interesting. Have you done any testing with any of the
Gallium drivers?
How difficult
On Fri, May 30, 2014 at 05:31:10PM +0200, Bruno Jiménez wrote:
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Tom Stellard thomas.stell...@amd.com
diff --git a/src/gallium/docs
On Fri, May 30, 2014 at 05:31:12PM +0200, Bruno Jiménez wrote:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/state_trackers/clover/api/device.cpp | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1
On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
And with the attached patch as #2 for my series I can get the correct
number of compute units for my CEDAR.
But I don't know how or where I should add this
On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
And with the attached patch
On Mon, May 19, 2014 at 06:14:50PM +0200, Bruno Jiménez wrote:
Hi,
Firstly, I shall introduce myself (at least more formally than just
sending some patches). My name is Bruno Jiménez, I'm studying
physics at Zaragoza's University (Spain) and I am participating in
this year's Google Summer
On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
Bruno Jimenez brunoji...@gmail.com writes:
Hi,
I'm trying to make clover fail in the case that a kernel fails to build.
My first attempt has been to track a llvm compile failure up from
'radeon_llvm_compile' (at
On Thu, May 15, 2014 at 10:42:07PM +0200, Francisco Jerez wrote:
Tom Stellard t...@stellard.net writes:
On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
Bruno Jimenez brunoji...@gmail.com writes:
Hi,
I'm trying to make clover fail in the case that a kernel fails
On Tue, May 13, 2014 at 12:15:01AM +0100, Emil Velikov wrote:
Just fold libllvmradeon in libradeon.
For the series:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/drivers/r600/Makefile.am | 2 --
src/gallium
On Tue, May 13, 2014 at 11:35:36AM +0200, Francisco Jerez wrote:
Tom Stellard t...@stellard.net writes:
On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
Tom Stellard thomas.stell...@amd.com writes:
https://bugs.freedesktop.org/show_bug.cgi?id=78581
CC: 10.1 10.2
https://bugs.freedesktop.org/show_bug.cgi?id=78581
CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org
---
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
On Tue, May 13, 2014 at 01:23:03AM +0200, Francisco Jerez wrote:
Tom Stellard thomas.stell...@amd.com writes:
https://bugs.freedesktop.org/show_bug.cgi?id=78581
CC: 10.1 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
1
---
src/gallium/state_trackers/clover/core/device.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 2f84677..70b5caf 100644
---
The screen takes ownership of the winsys, and is responsible for
destroying it. Users of pipe-loader should make sure they destory
and screens they've created to avoid memory leaks.
This fixes a crash in clover introduced by
ce6c17c0833032e91a2d1b34f9eb80c738a854a2 where the pipe-loader was
v2:
- Make sure screen was successfully created before destroying it.
---
src/gallium/state_trackers/clover/core/device.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
The screen takes ownership of the winsys, and is responsible for
destroying it. Users of pipe-loader should make sure they destory
and screens they've created to avoid memory leaks.
This fixes a crash in clover introduced by
ce6c17c0833032e91a2d1b34f9eb80c738a854a2 where the pipe-loader was
---
src/gallium/state_trackers/clover/core/device.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 2f84677..70b5caf 100644
---
v2:
- Make sure screen was successfully created before destroying it.
---
src/gallium/state_trackers/clover/core/device.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
On Thu, May 08, 2014 at 11:38:13PM -0400, Tom Stellard wrote:
The screen takes ownership of the winsys, and is responsible for
destroying it. Users of pipe-loader should make sure they destory
and screens they've created to avoid memory leaks.
I did not mean to send this whole series again
---
configure.ac | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d6f21ea..c68db00 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1605,6 +1605,12 @@ if test x$enable_gallium_llvm = xyes; then
---
I tested this patch with LLVM 3.4, 3.4.1, and 3.5 and observed the
correct behavior for all three versions.
src/gallium/drivers/radeonsi/si_descriptors.c | 4 ++--
src/gallium/drivers/radeonsi/si_pipe.c| 4 ++--
src/gallium/drivers/radeonsi/si_pipe.h| 4
With that fixed:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
+ return mullins;
+#else
+ return kabini;
+#endif
default: return ;
#endif
}
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index
On Wed, Apr 30, 2014 at 06:58:26PM -0400, Alex Deucher wrote:
From: Samuel Li samuel...@amd.com
Committed as r207846.
-Tom
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
lib/Target/R600/Processors.td | 2 ++
1 file changed, 2
On Wed, Apr 30, 2014 at 07:30:15PM -0400, Alex Deucher wrote:
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
v2:
- Use c++ features
- Fix error code handling
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
v2:
- Use c++ features
- Fix error code handling
v3:
- Move iostream into api/util.hpp
- Fix indentation
---
v2:
- Write RASTER_CONFIG for all SEs
https://bugs.freedesktop.org/show_bug.cgi?id=60879
---
src/gallium/drivers/radeonsi/si_state.c | 100 --
src/gallium/drivers/radeonsi/sid.h| 8 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 +
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/dispatch.hpp | 8 +++-
On Wed, Apr 23, 2014 at 01:27:11PM +, Dorrington, Albert wrote:
In trying to implement Image support in Clover, I have discovered that the
existing CL image related calls result in the generation of Pixel Shader
sequences for copies of images to and from the GPU.
I initially thought
On Mon, Apr 21, 2014 at 10:02:27PM -0400, Jan Vesely wrote:
Hi,
I ran into a problem caused by this part of the OCL specs (6.1.5
Alignment of Types):
For 3-component vector data types, the size of the data type is 4 *
sizeof(component).
and the corresponding part of Khronos cl_platform.h
On Fri, Apr 18, 2014 at 06:59:37PM +0200, Kai Wasserbäch wrote:
Hi there,
Tom Stellard schrieb am 16.04.2014 17:07:
On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
Michel Dänzer schrieb am 15.04.2014 09:27:
On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm
with the environment variable R600_DEBUG=llvm.
Cc: 10.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/r600_pipe.c | 6 +++---
src/gallium/drivers/r600/r600_pipe.h | 2
On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
Michel Dänzer schrieb am 15.04.2014 09:27:
On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash
happens
in _int_malloc, but since that is
Hi,
I've been trying to get piglit working on radeon without X using gbm and
render-nodes, and the problem right now is that the radeon winsys is
trying to use DRM_IOCTL_GEM_OPEN, which is not allowed with render-nodes.
I'm not sure if we need to replace this ioctl with something else or
if the
On Wed, Apr 16, 2014 at 03:49:03AM +0200, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Just adjust to the ever-changing API, pass in MCContext when creating the
MCDisassembler.
---
src/gallium/auxiliary/gallivm
On Thu, Apr 10, 2014 at 03:24:32PM +, Dorrington, Albert wrote:
I am having an issue with a memory leak in an OpenCL program I am testing.
In the program I call the same kernel repeatedly, for every pixel in an
image. (Probably not the most efficient code, but it is a learning/testing
From: Darren Powell darren.pow...@amd.com
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 34 ---
src/gallium/drivers/radeonsi/si_shader.c | 12 +++---
src/gallium/drivers/radeonsi/si_state.c | 2 ++
3 files changed, 42 insertions(+), 6 deletions(-)
On Mon, Mar 31, 2014 at 06:39:26PM +, Dorrington, Albert wrote:
I am experimenting with adding image support to Mesa and am encountering
something I don't understand with the mapping routines implemented in
transfer.cpp, within the soft_copy_op function.
We are working on 10.1 branch
On Mon, Mar 24, 2014 at 02:35:04PM +, Dorrington, Albert wrote:
I have been experimenting with adding image support to the clover
implementation, and have been trying to understand the differences between
the existing buffer support and what would be required to support images.
From
On Fri, Mar 21, 2014 at 05:47:56PM +0100, Christian Zigotzky wrote:
Hi All,
I have compiled LLVM 3.4 and Mesa 10.0.4 without any changes.
Here is the result of this test.
- glxinfo | grep OpenGL
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
).
Don't worry if you don't have a supported AMD GPU. If your proposal is
accepted there will be plenty of time for you to get one and many of the
older Evergreen GPUs can be obtained very inexpensively.
-Tom
On Tue, Mar 18, 2014 at 9:14 PM, Tom Stellard t...@stellard.net wrote:
On Mon
to be where other libs also reside.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76082
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
configure.ac | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure.ac b/configure.ac
On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote:
Hi,
I am a student. I have experience in OpenCL for 3 years. I would like to
know what need to be done exactly.
Hi,
The first thing you need to do is write a proposal. I would recommend
writing a rough draft, uploading it to
On Mon, Mar 17, 2014 at 03:36:37PM +, Dorrington, Albert wrote:
I'm curious if there is any way to reset/restart the video card via Mesa or
the libdrm drivers?
I'm currently doing development against the OpenCL drivers, and getting the
video card into a state where is will not respond.
On Sun, Mar 16, 2014 at 12:14:29AM +0100, Marek Skalický wrote:
Hi,
My name is Marek Skalický. I am 20 years old and I study Applied
informatics at Masaryk university in Brno.
And I am interested in GSoC project about implementing OpenCL Image
Support into r600g/radeonsi.
I would like to
a full run on my Boanire system without hangs, so I would
feel better
if someone else was able to test these.
-Tom
From a31bd001e5b2705c32edce4950bb403c1dc1f010 Mon Sep 17 00:00:00 2001
From: Tom Stellard thomas.stell...@amd.com
Date: Tue, 11 Mar 2014 10:11:55 -0400
Subject: [PATCH 1/3] R600/SI: Add
On Tue, Mar 11, 2014 at 12:37:15PM -0400, Jan Vesely wrote:
On Tue, 2014-03-11 at 11:37 -0400, Jan Vesely wrote:
On Tue, 2014-03-11 at 15:09 +0100, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
v2: - allow byte-aligned DMA buffer copies on Evergreen
- fix
On Sun, Mar 09, 2014 at 12:28:01AM +0530, ANUJ SHARMA wrote:
Hello Sir ,
I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian
Institute of Technology, Kanpur, India.
Sir Where Can i get the more detail on what should we need to implement for
the OpenCL Image Support.
Hi
This fixes the a build breakage caused by
6974eb907600b9d0176d3158ff0fd30ac3e56a55 on build configurations where
all the following are true:
1. radeonsi is not being built
2. r600g is being built
3. opencl is disabled
4. --enable-r600-llvm-compiler is not being used
5. libelf is not installed
---
This fixes the a build breakage caused by
6974eb907600b9d0176d3158ff0fd30ac3e56a55 on build configurations where
all the following are true:
1. radeonsi is not being built
2. r600g is being built
3. opencl is disabled
4. --enable-r600-llvm-compiler is not being used
5. libelf is not installed
On Thu, Mar 06, 2014 at 11:57:29AM +0900, Michel Dänzer wrote:
On Mit, 2014-03-05 at 21:25 -0500, Tom Stellard wrote:
And move its definition into r600_pipe_common.h; This struct is a just
a container for shader code and has nothing to do with LLVM.
Well, it has something to do with LLVM
On Thu, Mar 06, 2014 at 01:45:36PM +0100, Francisco Jerez wrote:
Tom Stellard thomas.stell...@amd.com writes:
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 35 --
.../state_trackers/clover/core/compiler.hpp| 3 +-
src/gallium/state_trackers/clover/core
On Fri, Mar 07, 2014 at 10:49:59AM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
llvm/Linker.h was moved to llvm/Linker/Linker.h.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/state_trackers
And move its definition into r600_pipe_common.h; This struct is a just
a container for shader code and has nothing to do with LLVM.
---
src/gallium/drivers/r600/r600_llvm.c | 4 ++--
src/gallium/drivers/radeon/Makefile.am| 1 +
src/gallium/drivers/radeon/r600_pipe_common.h |
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 35 --
.../state_trackers/clover/core/compiler.hpp| 3 +-
src/gallium/state_trackers/clover/core/device.cpp | 6 +++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors: Tom Stellard thomas.stell...@amd.com
+ *
+ */
+
+#include radeon_elf_util.h
+#include r600_pipe_common.h
These are sometimes created by the shrink to boolean optimization in the
globalopt pass.
---
lib/Target/R600/SIISelLowering.cpp | 6 ++
test/CodeGen/R600/store.ll | 23 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git
please update the wiki [1]. Currently it lists the old configure
switch --with-llvm-shared-libs
I've updated the wiki.
The patch is:
Reviewed-by: Tom Stellard thomas.stell...@amd.com
[1] http://dri.freedesktop.org/wiki/GalliumCompute/
Cc: Tom Stellard thomas.stell...@amd.com
Signed-off
---
This patch should work for older LLVM versions too.
configure.ac | 5 +
src/gallium/state_trackers/clover/Makefile.am | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 0e0fd18..a1eb907 100644
---
On Sat, Mar 01, 2014 at 11:51:24PM +0100, Bruno Jiménez wrote:
Recently, llvm has changed to use c++11, so we also should use it
---
src/gallium/state_trackers/clover/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Mon, Mar 03, 2014 at 08:03:23AM -0800, Tom Stellard wrote:
---
This patch should work for older LLVM versions too.
Disregard this, there is a better fix already on the list.
-Tom
configure.ac | 5 +
src/gallium/state_trackers/clover/Makefile.am
On Mon, Mar 03, 2014 at 08:05:26AM -0800, Tom Stellard wrote:
On Sat, Mar 01, 2014 at 11:51:24PM +0100, Bruno Jiménez wrote:
Recently, llvm has changed to use c++11, so we also should use it
---
src/gallium/state_trackers/clover/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2
-by: Tom Stellard thomas.stell...@amd.com
---
v3:
* Use VSrc_32 for the SI_KILL operand.
* Drop unused Depth parameter from SILowerControlFlowPass::Kill().
* Use local variable 'Op' also in else path.
lib/Target/R600/SIInstructions.td | 4 ++--
lib/Target/R600
On Tue, Feb 25, 2014 at 07:36:46PM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
v2:
* Bail in SILowerControlFlowPass::SkipIfDead() for geometry shaders
On Tue, Feb 25, 2014 at 07:36:47PM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
Make a call to R600's implementation of verifyInstruction() to
check that instructions are only using legal operands.
---
lib/Target/R600/AMDGPUMCInstLower.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/lib/Target/R600/AMDGPUMCInstLower.cpp
---
lib/Target/R600/SIISelLowering.cpp | 2 +-
test/CodeGen/R600/add.ll | 40 ++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/lib/Target/R600/SIISelLowering.cpp
b/lib/Target/R600/SIISelLowering.cpp
index ffa42b8..3b7043a 100644
---
On Tue, Feb 25, 2014 at 01:47:17PM -0800, Matt Arsenault wrote:
On 02/25/2014 01:42 PM, Tom Stellard wrote:
+errs() Please file a bug a bugs.freedesktop.org\n;
Typo, s/a/at/
Thanks, I will fix this before I commit.
-Tom
___
llvm-commits
On Tue, Feb 25, 2014 at 02:26:34PM -0800, Timothy Arceri wrote:
Hi Tom,
I managed to accidentally revert your commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=fcd499730b225ec5a35902893c059086ba11b590
I managed to commit the same change:
assume the llvm.org/bugs link comes from in the output from a crash)
On Tue, Feb 25, 2014 at 1:54 PM, Tom Stellard t...@stellard.net wrote:
On Tue, Feb 25, 2014 at 01:47:17PM -0800, Matt Arsenault wrote:
On 02/25/2014 01:42 PM, Tom Stellard wrote:
+errs() Please file a bug
These four patches fix the OpenCL build errors.
Tested-by: Tom Stellard thomas.stell...@amd.com
On Sat, Feb 22, 2014 at 04:53:47PM +, Emil Velikov wrote:
When one builds without gallium_drm_loader, the above function will
not be available, thus we'll segfault in gallium_screen_create due
+++ b/test/CodeGen/R600/llvm.AMDGPU.kill.ll
@@ -0,0 +1,18 @@
+; RUN: llc %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck
--check-prefix=SI-CHECK %s
+
+; SI-LABEL: @kill_gs
Since your prefix is SI-CHECK, this would need to be SI-CHECK-LABEL.
With that fix,
Reviewed-by: Tom
This prevents clover from using unsupported devices.
---
src/gallium/drivers/r600/r600_pipe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 0f75a53..157d560 100644
---
On Thu, Feb 20, 2014 at 09:53:22PM -0800, Matt Turner wrote:
On Thu, Feb 20, 2014 at 10:21 AM, Tom Stellard thomas.stell...@amd.com
wrote:
---
configure.ac| 6 ++
m4/ax_gcc_builtin.m4| 168
src/gallium
On Fri, Feb 21, 2014 at 05:53:02PM +, Dorrington, Albert wrote:
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
You are seeing a GPU hang and the driver attempts to reset it which doesn't
always work. Probably a problem in the OpenGL or OpenCL driver in
On Fri, Feb 21, 2014 at 09:48:50PM +, Dorrington, Albert wrote:
-Original Message-
From: Tom Stellard [mailto:t...@stellard.net]
Subject: Re: [Mesa-dev] EXTERNAL: Re: Radeon
r600_ring_test/evergreen_resume errors
On Fri, Feb 21, 2014 at 05:53:02PM +, Dorrington, Albert
---
src/gallium/drivers/r600/r600_asm.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 2 +-
src/gallium/drivers/r600/r600_state_common.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
---
src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index d45bc80..9b10d01
The offsets will be stored in the handles parameter. This makes
it possible to use sub-buffers.
v2:
- Style fixes
- Add support for constant sub-buffers
- Store handles in device byte order
v3:
- Use endian helpers
---
src/gallium/drivers/r600/evergreen_compute.c | 7 ++-
---
src/gallium/auxiliary/util/u_math.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 0f498bc..ffbcc4c 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -726,6
---
configure.ac| 6 ++
m4/ax_gcc_builtin.m4| 168
src/gallium/auxiliary/util/u_math.h | 3 +-
3 files changed, 176 insertions(+), 1 deletion(-)
create mode 100644 m4/ax_gcc_builtin.m4
diff --git a/configure.ac
---
src/gallium/state_trackers/clover/core/resource.cpp | 2 +-
src/gallium/state_trackers/clover/core/resource.hpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/resource.cpp
b/src/gallium/state_trackers/clover/core/resource.cpp
---
src/gallium/drivers/radeonsi/si_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 9b04e6b..7776821 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++
v2:
- Use __builtin_bswap64()
- Remove unnecessary mask
- Add util_le64_to_cpu() helper
---
configure.ac| 2 ++
src/gallium/auxiliary/util/u_math.h | 16
2 files changed, 18 insertions(+)
diff --git a/configure.ac b/configure.ac
index
On Wed, Feb 19, 2014 at 09:20:22PM +, Dorrington, Albert wrote:
Currently clGetDeviceInfo() returns an empty string when queried for
CL_DEVICE_EXTENSIONS.
Looking through both the Mesa and LLVM/Clang code I see references to the
following extensions:
cl_khr_fp64
On Tue, Feb 18, 2014 at 05:50:19PM +0100, Francisco Jerez wrote:
Tom Stellard t...@stellard.net writes:
From: Tom Stellard thomas.stell...@amd.com
After pipe_loader_release() is called, if any of the pipe_* objects
try to call into the gallium API the application will segfault
501 - 600 of 1623 matches
Mail list logo