From: Tom Stellard
---
lib/Target/R600/MCTargetDesc/AMDGPUAsmBackend.cpp | 29 ++--
.../R600/MCTargetDesc/AMDGPUELFObjectWriter.cpp| 39 ++
.../R600/MCTargetDesc/AMDGPUMCTargetDesc.cpp | 2 +-
lib/Target/R600/MCTargetDesc/AMDGPUMCTargetDesc.h | 4
From: Tom Stellard
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps require that
the
From: Tom Stellard
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps require that
the
From: Tom Stellard
Using a NULL value for the platform_id is legal according to the spec,
however, passing a NULL value as the platform parameter to
clGetPlatformInfo() results in implementation defined behavior.
In order to avoid implementation defined behavior some apps require that
the
On Sun, Apr 07, 2013 at 09:45:35PM +0200, Vincent Lejeune wrote:
> This fixes bug 62756 :
> https://bugs.freedesktop.org/show_bug.cgi?id=62756#c12
>
> (Requires corresponding llvm commit)
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/r600/r600_asm.c | 6 +-
&g
On Sun, Apr 07, 2013 at 09:43:43PM +0200, Vincent Lejeune wrote:
Reviewed-by: Tom Stellard
> ---
> lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 30 ++--
> lib/Target/R600/R600ControlFlowFinalizer.cpp | 84 +++--
> lib/Target/R600/R600Instructions.td
On Thu, Apr 04, 2013 at 11:26:45PM +0200, Niels Ole Salscheider wrote:
> Clover needs the irreader component of llvm
>
> v2: Check for irreader component
> irreader is only available with LLVM 3.3 >= 177971
>
> Signed-off-by: Niels Ole Salscheider
I've pushed this, thanks.
btw, I also pushed y
On Tue, Apr 09, 2013 at 11:38:42PM +0200, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> lib/Target/R600/R600ControlFlowFinalizer.cpp | 11 ++-
> test/CodeGen/R600/loop-adress.ll | 44
>
> 2 files changed, 54 insertions
rc_32:$src0
> +>;
> +
We should start using the updated pattern syntax for all new patterns.
This means replacing register classes with types for the input patterns
and omitting the type in the output pattern:
def : Pat <
(AMDGPUurecip i32:$src0),
(V_CVT_U32_F32_e32
(V_MUL_F32_e32 CO
On Wed, Apr 10, 2013 at 11:04:21PM +0200, Vincent Lejeune wrote:
> ---
> lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 15 +--
> lib/Target/R600/R600Instructions.td| 8
> 2 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/lib/Target/R60
On Wed, Apr 10, 2013 at 11:04:20PM +0200, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> lib/Target/R600/AMDGPUAsmPrinter.cpp | 35 +--
> lib/Target/R600/AMDGPUAsmPrinter.h | 3 ++-
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
On Wed, Apr 10, 2013 at 11:04:22PM +0200, Vincent Lejeune wrote:
> ---
Could you add a comment explaining why export instructions are not
duplicable. With that change:
Reviewed-by: Tom Stellard
> lib/Target/R600/R600Instructions.td | 2 +-
> 1 file changed, 1 insertion(+), 1
From: Tom Stellard
Instead of emitting configuration values (e.g. number of gprs used) in a
predefined order, the LLVM backend now emits these values in
register/value pairs. The first dword contains the register address and
the second dword contians the value to write.
---
src/gallium/drivers
On Thu, Apr 11, 2013 at 01:07:50PM +0530, Sreyanth wrote:
> Hi all
>
> I am interested to participate in GSoC this year in X.org. I have gone
> through the proposed ideas and I am interested in working on finding common
> patterns in real GLSL shaders.
>
> I understand that this is a datamining p
From: Tom Stellard
---
r600/lib/workitem/get_group_id.ll | 12 ++--
r600/lib/workitem/get_local_size.ll | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/r600/lib/workitem/get_group_id.ll
b/r600/lib/workitem/get_group_id.ll
index 5131648..0dc86e5
On Thu, Apr 11, 2013 at 01:08:40PM +, Akshay Murarka wrote:
> I wanted to know if it would be possible for me to do the project if I am a
> good coder in the C language but have never used OpenGL.If you would guide me
> from were to read then I would definitely do that .
nterfaces in
> ${function_name}.ll which are implemented in ${function_name}_impl.ll.
>
> Renaming the interface files is enough to get them to build again, fixing
> CL usage of these functions.
>
> Tested on clover/r600g.
Reviewed-by: Tom Stellard
> ---
> generic/lib/SOURCES
On Sat, Apr 13, 2013 at 11:22:51AM -0500, Aaron Watry wrote:
> Implements the min() OpenCL built-in in 2 stages.
> 1) Implement min() where the two argument types match
> 2) Make changes to support min(vec,scalar)
>
For the series:
Reviewed-by:
On Mon, Apr 15, 2013 at 07:20:31PM -0500, Aaron Watry wrote:
Reviewed-by: Tom Stellard
> Squashed commit of the following:
>
> commit a0df0a0e86c55c1bdc0b9c0f5a739e5adef4b056
> Author: Aaron Watry
> Date: Mon Apr 15 18:42:04 2013 -0500
>
> libclc: Rename clz.ll to c
On Sat, Apr 13, 2013 at 11:32:18AM -0500, Aaron Watry wrote:
> For any GENTYPE that isn't scalar, we need to implement a mixed
> vector/scalar version of clamp/max.
>
> This depends on the min() patches I sent to the list a few minutes ago.
Reviewed-by: Tom Stellard
> --
From: Tom Stellard
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
---
src/gallium/drivers/radeon/Makefile.am | 2 -
src/gallium/drivers/radeon/Makefile.sources | 4 +-
src
From: Tom Stellard
SGPRs are spilled into VGPRs using the {READ,WRITE}LANE_B32 instructions.
v2:
- Fix encoding of Lane Mask
- Use correct register flags, so we don't overwrite the low dword
when restoring multi-dword registers.
v3:
- Register spilling seems to hang the GP
On Sat, Nov 23, 2013 at 03:30:30PM -0800, Ian Romanick wrote:
> I believe that I have picked over all of the patches marked for the 10.0
> release branch. I have included the full list far below. There are a
> few patches that were sent to the mesa-stable mailing list that do not
> appear to have l
From: Tom Stellard
CC: "9.2" "10.0"
---
.../r300/compiler/tests/radeon_compiler_regalloc_tests.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
a/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c
b/src/gallium/d
From: Tom Stellard
CC: "9.2" "10.0"
---
src/gallium/drivers/r300/compiler/tests/rc_test_helpers.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r300/compiler/tests/rc_test_helpers.c
b/src/gallium/drivers/r300/compiler/tests/rc_
On Wed, Dec 04, 2013 at 03:11:16PM +0100, Vincent Lejeune wrote:
> ---
> src/gallium/drivers/radeon/radeon_llvm.h | 5 +++
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 41
> +++---
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/src/galli
On Fri, Dec 06, 2013 at 10:43:42PM +0100, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> src/gallium/drivers/radeon/radeon_llvm.h | 6 +++
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 43
> --
> 2 files changed, 45 insertions(
On Sat, Dec 07, 2013 at 07:06:36PM +0400, Vadim Girlin wrote:
> On evergreen we have to reserve 1 stack element in some additional cases
> besides the ones mentioned in the docs, but stack size computation was
> recently reimplemented exactly as described in the docs by the patch that
> added worka
rom 28e45d4418b7a086651aaba3eda1150472aca928 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 2 Dec 2013 12:37:14 -0800
Subject: [PATCH 1/4] R600: Register R600EmitClauseMarkers pass
This enables -print-before-all to dump MachineInstrs after it is run.
---
lib/Target/R600/AMDGPU.h |
On Tue, Dec 10, 2013 at 02:54:46AM +0400, Vadim Girlin wrote:
> On Mon, 2013-12-09 at 10:56 -0500, Tom Stellard wrote:
> > On Sat, Dec 07, 2013 at 07:06:36PM +0400, Vadim Girlin wrote:
> > > On evergreen we have to reserve 1 stack element in some additional cases
> > >
Hi,
The attached patches implement a work-around for the CF stack HW bug
that is present on some Evergreen and NI GPUs.
Please Review.
-Tom
>From 7653598e8f3b111643348caa0aad5ff0f8859fe6 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 6 Dec 2013 16:19:40 -0800
Subject: [PATCH 1/6] R
On Thu, Dec 12, 2013 at 04:47:20PM -0600, Aaron Watry wrote:
> ---
> 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 10
Hi Aaron,
Just one comment on patch 4, with that fixed the series is:
Reviewed-by: Tom Stellard
If you re-send an annotated series with the patch 4 fix I'll push it.
Also, can you add
CC: "10.0"
so they get pulled into the stable branch.
Thanks,
Tom
On Thu, Dec 12, 201
On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
> Hi all,
>
> Is there a way to see the machine code that is generated by the GLSL
> compiler for all GPU instruction sets? For example, I would like to know if
> the optimizer optimizes certain (equivalent) constructs (or not), and
On Wed, Dec 18, 2013 at 03:41:09PM -0500, Jan Vesely wrote:
> v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc
>
> Signed-off-by: Jan Vesely
> ---
> lib/Target/R600/AMDGPUISelLowering.cpp | 2 ++
> lib/Target/R600/R600Instructions.td| 2 ++
> 2 files changed, 4 insertions(
On Wed, Dec 18, 2013 at 04:50:53PM -0500, Jan Vesely wrote:
> v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc
> v3: move ftrunc pattern next to TRUNC definition, it's available since R600
>
I've pushed this patch, thanks!
I forgot to remind you to add a test case, so I added
On Sat, Jan 04, 2014 at 01:27:29AM +0100, Bruno Jiménez wrote:
> ---
Reviewed-by: Tom Stellard
> src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
> b/s
On Sat, Jan 04, 2014 at 01:27:31AM +0100, Bruno Jiménez wrote:
> In this case, NULL checks are added to compute_memory_grow_pool,
> so it returns -1 when it fails. This makes necesary
> to handle such cases in compute_memory_finalize_pending
> when it is needed to grow the pool
> ---
> src/gallium
On Sat, Jan 04, 2014 at 01:27:30AM +0100, Bruno Jiménez wrote:
> ---
Reviewed-by: Tom Stellard
> src/gallium/drivers/r600/compute_memory_pool.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
> b/src/ga
On Sat, Jan 04, 2014 at 01:27:33AM +0100, Bruno Jiménez wrote:
> It seems to be unimplemented.
>
> I think that this function would have been the one that
> solves the problem with fragmentation that
> compute_memory_finalize_pending has.
Reviewed-by: Tom Stellard
> ---
>
On Sat, Jan 04, 2014 at 01:27:32AM +0100, Bruno Jiménez wrote:
> ---
> src/gallium/drivers/r600/compute_memory_pool.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
> b/src/gallium/drivers/r600/compute_m
On Sat, Jan 04, 2014 at 06:28:27PM +0100, Bruno Jimenez wrote:
> On Sat, 2014-01-04 at 08:52 -0800, Tom Stellard wrote:
> > On Sat, Jan 04, 2014 at 01:27:32AM +0100, Bruno Jiménez wrote:
> > > ---
> > > src/gallium/drivers/r600/compute_memory_pool.c | 18 +++--
On Sat, Jan 04, 2014 at 10:25:52PM +0100, Bruno Jimenez wrote:
> On Sat, 2014-01-04 at 13:08 -0800, Tom Stellard wrote:
>
> [snip]
>
> > >
> > > So, you were wright, I changed the behaviour for
> > > need == 0. But just checking for need < 0 should
&
From: Tom Stellard
The xvmc unit tests are failing on r300g and r600g.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index f75325d..d41455b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -583,7 +583,7 @@ AC_ARG_ENABLE([xvmc
From: Tom Stellard
---
src/gallium/drivers/r300/compiler/radeon_program.h | 2 ++
src/gallium/drivers/r300/compiler/radeon_program_print.c | 13 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_program.h
b/src/gallium
From: Tom Stellard
---
.../drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c
b/src/gallium/drivers/r300/compiler/tests
From: Tom Stellard
---
.../drivers/r300/compiler/tests/README.test| 26
.../drivers/r300/compiler/tests/rc_test_helpers.c | 77 --
.../drivers/r300/compiler/tests/rc_test_helpers.h | 7 ++
3 files changed, 105 insertions(+), 5 deletions(-)
create mode
From: Tom Stellard
---
.../r300/compiler/tests/omod_two_writers.test | 5 +++
.../tests/radeon_compiler_optimize_tests.c | 49 +++---
.../tests/radeon_compiler_regalloc_tests.c | 13 +-
.../compiler/tests/regalloc_tex_1d_swizzle.test| 1 +
4 files
From: Tom Stellard
---
src/gallium/drivers/r300/compiler/tests/rc_test_helpers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/tests/rc_test_helpers.c
b/src/gallium/drivers/r300/compiler/tests/rc_test_helpers.c
index b4e30d8..725be4c
On Sun, Jan 05, 2014 at 09:49:53PM -0500, Ilia Mirkin wrote:
> On Sun, Jan 5, 2014 at 9:49 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > The xvmc unit tests are failing on r300g and r600g.
>
> FWIW it works fine on nv40-nv96. (Haven't checked
-gnu-llvm-config for 32-bit multilib LLVM.
>
Reviewed-by: Tom Stellard
Should we CC stable on this patch? Do you have commit access?
-Tom
> Signed-off-by: Michał Górny
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73100
> ---
> configure.ac | 4 ++--
> 1 file
On Mon, Jan 06, 2014 at 11:47:39AM +0200, Lauri Kasanen wrote:
> On Sun, 5 Jan 2014 18:51:18 -0800
> Tom Stellard wrote:
>
> > struct rc_test_file test_file;
> > + struct rc_instruction *inst;
> > unsigned optimizations = 1;
> > unsigned do_
On Thu, Jan 09, 2014 at 02:57:20PM +, christophe choquet wrote:
> Hi,
>
> I am using kernel 3.12.6-gentoo, Mesa 10.0.1 and once every two calls to
> clBuildProgram, the GPU goes to reset after 10 seconds.
> This also happens on Debian unstable with Mesa 9.2. First hello_world works,
> the ne
On Thu, Jan 09, 2014 at 12:49:51PM +, Dorrington, Albert wrote:
> I am not sure if this is the appropriate list on which to ask this question,
> if not hopefully someone can suggest an alternative.
>
> Under Linux, I am attempting to perform an offline compile of an OpenCL
> kernel example u
On Sat, Jan 11, 2014 at 03:53:58PM +, Emil Velikov wrote:
> Hello list,
>
> While going though mesa's build systems I was wondering what it would
> take to improve the overall experience of build testing.
>
> The only thing I can think of is a more centralised solution similar to
> the one us
On Sun, Jan 12, 2014 at 03:08:56AM +0400, Igor Gnatenko wrote:
> From 5b2bf87f1238e44150492a39f5db0ae90d59459b Mon Sep 17 00:00:00 2001
> From: Igor Gnatenko
> Date: Sun, 12 Jan 2014 02:09:16 +0400
> Subject: [PATCH] opencl: improved auto-gen .icd
>
> v2: Use @OPENCL_VERSION@:0 for library
>
rogram (I think) I'm not too
> worried about using clang/llvm directly yet.
>
> Thanks!
> -Al
>
> -Original Message-
> From: Tom Stellard [mailto:t...@stellard.net]
> Sent: Monday, January 13, 2014 1:12 PM
> To: Dorrington, Albert
> Cc: mesa-dev@lists.freede
On Mon, Jan 13, 2014 at 07:04:44PM +0100, Michał Górny wrote:
> Dnia 2014-01-13, o godz. 08:59:22
> Tom Stellard napisał(a):
>
> > On Sat, Dec 28, 2013 at 03:22:09PM +0100, Michał Górny wrote:
> > > This should help with cross-compiling and multilib when $CHOST-speci
On Tue, Jan 14, 2014 at 10:05:47AM +0100, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Mon, Jan 13, 2014 at 06:44:15PM +, Dorrington, Albert wrote:
> >> Tom,
> >>
> >> Thanks for your response. I am very interested in implementing this, so
From: Tom Stellard
This enables piglit to run and interpret the results from OpenCV's
gtest based opencv_test_ocl program.
This patch adds two new CMake configuration variables:
OPENCL_OpenCVTestOCL_BINDIR: You can use this variable to enable
the OpenCV tests by setting it to the full pa
On Sun, Jan 19, 2014 at 09:20:54AM -0800, ian_br...@fastmail.net wrote:
> This page:
>
> http://dri.freedesktop.org/wiki/GalliumCompute/
>
> says "Evergreen through Southern Islands GPU families are currently
> supported."
>
> It's unclear (at least to me) whether HD7790 ("Sea Islands") cards ar
On Fri, Jan 17, 2014 at 03:04:46PM -0800, Dylan Baker wrote:
> I think you meant to ping the piglit list not mesa dev :)
>
> In general this looks a lot better, I've got a few little things for you
>
> On Friday, January 17, 2014 02:30:13 PM Tom Stellard wrote:
&g
On Mon, Jan 20, 2014 at 11:14:18AM -0800, ian_br...@fastmail.net wrote:
> On Mon, 20 Jan 2014 08:00:39 -0800
> Tom Stellard wrote:
>
> >> http://dri.freedesktop.org/wiki/GalliumCompute/
>
> >> Could anybody clarify whether the information on the wiki page should
On Mon, Jan 20, 2014 at 09:32:11PM +, Hrustich, John wrote:
> The compute memory pool used by the gallium r600 driver seems to be
> problematic. The pool looks to be a single radeon buffer object. There
> could be multiple maps set up into that single buffer object. If there is a
> need t
On Wed, Jan 22, 2014 at 09:13:14PM +0100, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/radeonsi/si_blit.c| 5 ++---
> src/gallium/drivers/radeonsi/si_commands.c| 1 -
> src/gallium/drivers/radeonsi/si_
On Fri, Jan 24, 2014 at 01:27:00PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes half a dozen piglit tests with radeonsi.
>
> Signed-off-by: Michel Dänzer
> ---
> lib/Target/R600/SIInstructions.td | 5 +
> test/CodeGen/R600/trunc.ll| 10 ++
> 2 files changed,
On Fri, Jan 24, 2014 at 03:17:04PM +0900, Michel Dänzer wrote:
>
> The attached patches add two intrinsics to the R600 backend which are
> necessary for geometry shader support in the radeonsi driver.
>
Patch 1 and v2 of Patch 2 are:
Reviewed-by: Tom Stellard
-Tom
>
&g
From: Tom Stellard
This is necessary to prevent the next SURFACE_SYNC packet from
hanging the GPU.
https://bugs.freedesktop.org/show_bug.cgi?id=73418
CC: "9.2" "10.0"
---
src/gallium/drivers/r600/evergreen_compute.c | 9 -
src/gallium/drivers/r600/evergreend.
On Mon, Jan 27, 2014 at 04:43:14PM +0900, Michel Dänzer wrote:
> On Fre, 2014-01-24 at 07:40 -0800, Tom Stellard wrote:
> > On Fri, Jan 24, 2014 at 01:27:00PM +0900, Michel Dänzer wrote:
> > > From: Michel Dänzer
> > >
> > > Fixes half a dozen piglit tests wi
From: Tom Stellard
The caller can use this boolean to parameter to tell the pipe-loader
to authenticate with the X server when probing a file descriptor.
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h | 6 +-
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 +---
src
From: Tom Stellard
v2:
- Add missing call to pipe_loader_drm_release()
- Fix render node macros
- Drop render-node configure option
---
For reference, version 1 of this patch:
http://lists.freedesktop.org/archives/mesa-dev/2013-October/047296.html
.../auxiliary/pipe-loader
From: Tom Stellard
r600g and radeonsi have different implementations of resource_create.
https://bugs.freedesktop.org/show_bug.cgi?id=74139
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 -
src/gallium/drivers/radeonsi/si_pipe.c| 1 +
2 files changed, 1 insertion(+), 1 deletion
On Wed, Jan 29, 2014 at 06:23:00PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> V_ADD_F32 with source modifier does not produce -0.0 for this. Just
> manipulate the sign bit directly instead.
>
That's strange, so does this mean we can never use these modifiers?
> Also add a pattern fo
On Tue, Jan 28, 2014 at 03:04:00PM +0100, David Herrmann wrote:
> Hi Tom
>
> On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > v2:
> >- Add missing call to pipe_loader_drm_release()
> >- Fix render node macros
>
On Mon, Jan 27, 2014 at 05:22:06PM +0100, Erik Faye-Lund wrote:
> On Mon, Jan 27, 2014 at 5:13 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > The caller can use this boolean to parameter to tell the pipe-loader
>
> Boolean to parameter? A superfluous "to
;
> which is kind of funny combination of messages.
>
> regards,
> Jan
>
> PS: $ ls /dev/dri/
> card0 controlD64 renderD128
>
> On Thu, 2014-01-30 at 11:34 -0500, Tom Stellard wrote:
> > On Tue, Jan 28, 2014 at 03:04:00PM +0100, David Herrmann wrote:
> > &
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 bran
From: Darren Powell
---
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(-)
diff --git a/src/galliu
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
>
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 p
On Wed, Apr 16, 2014 at 03:49:03AM +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
Reviewed-by: Tom Stellard
> Just adjust to the ever-changing API, pass in MCContext when creating the
> MCDisassembler.
> ---
> src/gallium/auxiliary/gallivm/lp_bl
t runtime by default. It can be
> enabled with the environment variable R600_DEBUG=llvm.
>
> Cc: "10.1"
> Signed-off-by: Michel Dänzer
Reviewed-by: Tom Stellard
> ---
> 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
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,
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_p
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 though
On Mon, Apr 28, 2014 at 08:27:07PM +0200, Marek Olšák wrote:
> Please see my Mesa patch which moves index_bias to an SGPR. Doing it
> conditionally would be messy.
>
An alternative solution would be to give the function a target specific
calling convention and then create and implement that calli
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 +
src
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 +++-
s
On Wed, Apr 30, 2014 at 07:30:15PM -0400, Alex Deucher wrote:
> From: Samuel Li
>
> Signed-off-by: Samuel Li
> Signed-off-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
> src/gallium/drivers/radeonsi/si_state.c | 2 ++
> src/gallium/winsys/radeon/d
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 +-
src/gallium/s
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 into api/util.hpp
- Fix indentation
---
src/gallium/state_tr
uot;;
> + case CHIP_MULLINS:
> +#if HAVE_LLVM >= 0x305
The convention is to leave the leading zero when specifying LLVM version e.g:
#if HAVE_LLVM >= 0x0305
With that fixed:
Reviewed-by: Tom Stellard
> + return "mullins";
> +#else
> + retu
On Wed, Apr 30, 2014 at 06:58:26PM -0400, Alex Deucher wrote:
> From: Samuel Li
>
Committed as r207846.
-Tom
> Signed-off-by: Samuel Li
> Signed-off-by: Alex Deucher
> ---
> lib/Target/R600/Processors.td | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/Target/R600/Processors.
---
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
--- a/src/gallium/state_trackers/clover/
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
dest
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
b/src/gallium/state_trackers/clover/core/device.c
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
dest
---
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
--- a/src/gallium/state_trackers/clover/
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
b/src/gallium/state_trackers/clover/core/device.c
501 - 600 of 1703 matches
Mail list logo
