On Sun, Apr 24, 2016 at 6:27 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/r300/r300_reg.h | 20 +++--
> src/gallium/drivers/r300/r300_texture.c | 38
> ++---
> 2 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --g
On Mon, Apr 27, 2015 at 9:46 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 13 +++--
> src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++
> src/gallium/drivers/radeon/r600_query.c | 21
> +
On Mon, May 4, 2015 at 12:11 PM, Ilia Mirkin wrote:
> On Mon, May 4, 2015 at 12:47 PM, Tom Stellard wrote:
> > On Mon, May 04, 2015 at 10:13:19AM -0400, Ilia Mirkin wrote:
> >> On Mon, May 4, 2015 at 10:04 AM, Tom Stellard wrote:
> >> > On Sat, May 02, 2015 at 01:31:41PM -0400, Ilia Mirkin wrot
I'm not sure what the final consensus will be on how to do this, but FWIW:
Tested-By: Aaron Watry
I've tested this with 4 combinations:
no --with-opencl-icd option specified : libOpenCL.so gets installed in
${prefix}/lib
--with-opencl-icd=no : libOpenCL.so gets installed in ${prefix}/
On Thu, May 7, 2015 at 5:27 PM, Jan Vesely wrote:
> On Thu, 2015-05-07 at 21:52 +0200, EdB wrote:
> > Le 2015-05-07 18:55, Aaron Watry a écrit :
> > > I'm not sure what the final consensus will be on how to do this, but
> > > FWIW:
> > > Tested-By: Aaron
On Wed, Sep 24, 2014 at 8:31 AM, Timothy Arceri wrote:
> Hey guys,
>
> I don't think this is a Mesa issue but I didn't know where else to
> start. I tried using the #radeon channel but it wont let me post
> anything.
You have to be a registered user with nickserv on freenode to post in
#radeon, I
shader->code_bo was leaked VRAM
shader->bc.bytecode, shader->binary.* were leaked system memory.
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/sr
: Aaron Watry
CC: Ilia Mirkin
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium
v3: Rebase and add #if guards
v2: fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
Walk the array of cbufs backwards and free all of them.
v3: Rebase on top of changes since Aug 2014
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src
On Thu, Nov 13, 2014 at 6:22 PM, Ilia Mirkin wrote:
> On Thu, Nov 13, 2014 at 6:43 PM, Aaron Watry wrote:
>> dlopen allocates a string on dlopen failure which is retrieved via dlerror.
>> In
>> order to free that string, you need to retrieve and then free it.
>
> Ar
On Thu, Nov 13, 2014 at 7:04 PM, Ilia Mirkin wrote:
> On Thu, Nov 13, 2014 at 7:54 PM, Aaron Watry wrote:
>>
>> On Thu, Nov 13, 2014 at 6:22 PM, Ilia Mirkin wrote:
>> > On Thu, Nov 13, 2014 at 6:43 PM, Aaron Watry wrote:
>> >> dlopen allocates a string on d
Signed-off-by: Aaron Watry
CC: Ilia Mirkin
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/p
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin wrote:
> On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry wrote:
>> Signed-off-by: Aaron Watry
>> CC: Ilia Mirkin
>>
>> v4: Call dlerror() twice instead of freeing glibc's memory.
>> Prevents issues on C
. SI seems to have all the right de-references
in place, but I haven't verified that yet through actual run, just
inspection.
--Aaron
>
>> On Fri, Nov 14, 2014 at 12:43 AM, Aaron Watry wrote:
>>> Walk the array of cbufs backwards and free all of them.
>>>
>>&g
On a related note,
On Mon, Mar 23, 2015 at 2:19 PM, Jason Ekstrand
wrote:
> On Mon, Mar 23, 2015 at 11:19 AM, Bruno Jimenez
> wrote:
> > On Wed, 2015-03-18 at 16:37 -0700, Jason Ekstrand wrote:
> >> On Wed, Mar 18, 2015 at 4:27 PM, Connor Abbott
> wrote:
> >> > On Wed, Mar 18, 2015 at 2:58 PM,
On Sun, Apr 19, 2015 at 1:15 PM, Nick Sarnie
wrote:
> LLVM removed JITEmitDebugInfo from TargetOptions since they weren't used
>
> Signed-off-by: Nick Sarnie
> ---
> src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 2 +-
> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
> 2 files changed
Tested-By: Aaron Watry
On Sat, Feb 13, 2016 at 11:27 AM, Serge Martin wrote:
> ---
> src/gallium/state_trackers/clover/core/kernel.cpp | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp
To expand on what Sedat said here, make check is broken when building anv
at the moment. due to a combination of the genxml/isl/vulkan directory
moves.
I've been poking at it on one of my laptops over the last few days, but I
wouldn't complain if someone beat me to a fix.
--Aaron
On Tue, Feb 23,
To clarify, I've also been doing out-of-tree builds with make check and a
vulkan build (on a haswell system, but I don't think that matters at build
time).
On Tue, Feb 23, 2016 at 8:46 PM, Aaron Watry wrote:
> To expand on what Sedat said here, make check is broken when building
Well, I learned something from that (subject prefix), so I wouldn't mind
seeing it become more easily discoverable.
--Aaron
On Sun, Feb 28, 2016 at 7:25 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> On Mon, 2016-02-29 at 12:17 +1100, Timothy Arceri wrote:
> > From: Timothy Arceri
ee, and make check works
again.
--Aaron
>
>
>>
>> - Sedat -
>>
>> On 2/24/16, Aaron Watry wrote:
>> > To clarify, I've also been doing out-of-tree builds with make check and
>> a
>> > vulkan build (on a haswell system, but I don't thi
On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede wrote:
> Extend the MEMORY file support to differentiate between global, local
> and shared memory, as well as "input" memory.
>
> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a
> special memory type is added for this, since the
On Tue, May 31, 2016 at 11:26 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Signed-off-by: Emil Velikov
> ---
> src/mapi/glapi/gen/Makefile.am | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mapi/glapi/gen/Makefile.am
> b/src/mapi/glapi/gen/Makefile.am
> index c511de9..ab0dcab
On Mon, May 30, 2016 at 3:31 PM, Emil Velikov
wrote:
> On 30 May 2016 at 21:10, Jason Ekstrand wrote:
>
>> On Mon, May 30, 2016 at 12:27 PM, Emil Velikov
>> wrote:
>>
>>> Hi there,
>>> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>> > This patch enables compilation with -flto.
On Tue, May 31, 2016 at 4:57 PM, Martin Peres wrote:
> On 31/05/16 10:42, Eero Tamminen wrote:
>
>> Hi,
>>
>> On 30.05.2016 20:57, Rob Clark wrote:
>>
>>> On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote:
>>>
On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
git_sha1.c is generated in $(top_builddir)/src.
Fixes out-of-tree builds since 4825264f75c83576.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium
This also fixes 'make check' for me.
--Aaron
On Sat, Jun 18, 2016 at 9:06 PM, wrote:
> From: Roland Scheidegger
>
> Apparently, these are deprecated. There's some AutoUpgrade feature which
> is supposed to promote these to cmp/select, which apparently doesn't work
> with jit code. It is possib
On Mon, Jun 20, 2016 at 4:59 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> Hello.
>
> The result file at
> http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
> multiple issues, some of them are:
>
> [Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
> performance regressi
Hi Dave (and others),
I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR
(Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues.
1) Initially, I got an assertion in r600_add_atom stating that the atom ID
was not less than the R600_NUM_ATOMS value (id = 51, R600_NUM
On Thu, Dec 3, 2015 at 12:57 PM, Dave Airlie wrote:
>
> On 4 Dec 2015 03:01, "Aaron Watry" wrote:
> >
> > Hi Dave (and others),
> >
> > I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR
> (Radeon 5400, kernel 4.3.0) with Heave
Thanks from here as well.
I just last week received a haswell laptop to replace my evergreen-based
desktop at work (which will still be in service), so hopefully I will be
able to start poking at piglit/beignet a bit on that architecture as
well... It's nice to know that GL 4.0 is just hopefully
xture-float \
--enable-omx
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/dri/dri2.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index ef192e3..c466de7 100644
--- a/src/gallium/state_trackers/dri/d
On Sun, Aug 3, 2014 at 12:00 PM, Emil Velikov wrote:
> On 02/08/14 22:21, Aaron Watry wrote:
>> If building hardware drivers only, then kms_swrast_create_screen
>> won't be defined in inline_drm_helper.h and hardware drivers will
>> fail to dlopen as a result.
>>
On Sun, Aug 3, 2014 at 12:30 PM, Emil Velikov wrote:
> On 03/08/14 18:13, Aaron Watry wrote:
>> On Sun, Aug 3, 2014 at 12:00 PM, Emil Velikov
>> wrote:
>>
>> Yup, when I finally managed to bisect this down to the commit that
>> added the kms_swrast_create_sc
build_module_llvm(mod, kernels, address_spaces);
> + break;
> }
> +#if HAVE_LLVM >= 0x0306
> + // LLVM 3.6 and newer, the user takes ownership of the module.
> + delete mod;
> +#endif
> + return m;
> }
This is tested-by: Aaron Watry
It's basically
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/platform.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
b/src/gallium/state_trackers/clover/api/platform.cpp
index 81b0854..cf71593 100644
--- a/src
In that case, feel free to upgrade to a
Reviewed-by: Aaron Watry
On Thu, Aug 21, 2014 at 8:25 AM, Tom Stellard wrote:
> On Thu, Aug 21, 2014 at 08:20:57AM -0500, Aaron Watry wrote:
>> On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard
>> wrote:
>> > From: Michel Dänzer
&g
Compute on evergreen has slowly developed a few more memory leaks (or maybe
I had never finished fixing them all before).
One of the leaks got in when the memory pool work went in recently, the
others seem to have been around for a while.
The last patch (aux/pipe_loader) seems to affect more than
Tested on CEDAR
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index dcb7183..71a9218
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/compute_memory_pool.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 9324b84..55ff7d5 100644
--- a/src/gallium/drivers/r600
: Aaron Watry
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader
Walk the array of cbufs backwards and free all of them.
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index
On Thu, Aug 21, 2014 at 11:09 AM, Ilia Mirkin wrote:
> On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry wrote:
>> dlopen allocates a string on dlopen failure which is retrieved via dlerror.
>> In
>> order to free that string, you need to retrieve and then free it.
>>
: Aaron Watry
CC: Ilia Mirkin
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/pipe-loader
ingle-line comments.
--Aaron
On Thu, Aug 21, 2014 at 11:22 AM, Ilia Mirkin wrote:
> On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry wrote:
>> Signed-off-by: Aaron Watry
>> ---
>> src/gallium/drivers/r600/compute_memory_pool.c | 4
>> 1 file changed, 4 insertions(+
v2: Change to C-style comments and fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/compute_memory_pool.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index
Walk the array of cbufs backwards and free all of them.
v2: Change to C-style comments and fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b
Tested on CEDAR
v2: fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index
: Aaron Watry
CC: Ilia Mirkin
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 5 +
src/gallium/auxiliary/util/u_dl.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium
On Sat, Aug 23, 2014 at 10:01 AM, Bruno Jimenez wrote:
> On Thu, 2014-08-21 at 14:37 -0500, Aaron Watry wrote:
>> v2: Change to C-style comments and fix indentation
>>
>> Signed-off-by: Aaron Watry
>> ---
>> src/gallium/drivers/r600/compute_memory_pool.
Wrong list(s)? I don't see libclc-dev on the cc list.
Also:
Tested-by: Aaron Watry
On Mon, Aug 25, 2014 at 10:53 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> utils/prepare-builtins.cpp | 10 ++
> 1 file changed, 10
On Fri, May 26, 2017 at 10:56 AM, Marek Olšák wrote:
> I think this will break r600 clover support. I don't know if anybody uses
> it.
>
I just rebuild my desktop a month ago with a new Ryzen setup, which means
that my BARTS is actually in my old machine now. WIth the open-source
release of the
On Fri, May 26, 2017 at 12:03 PM, Jan Vesely wrote:
> On Fri, 2017-05-26 at 11:53 -0500, Aaron Watry wrote:
> > On Fri, May 26, 2017 at 10:56 AM, Marek Olšák wrote:
> >
> > > I think this will break r600 clover support. I don't know if anybody
> uses
> >
On Wed, May 31, 2017 at 3:14 PM, Jan Vesely wrote:
> On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote:
> > On 31 May 2017 at 18:18, Jan Vesely wrote:
> > > On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
> > > > On 31 May 2017 at 16:32, Marek Olšák wrote:
> > > > > On Wed, May 31, 2
On Wed, May 31, 2017 at 9:37 AM, Luke A. Guest wrote:
> Hi,
>
> I've just reinstalled Gentoo on my machine and I no longer have
> AMDGPU-Pro on it due to it using ancient libs. My machine is an FX-8350
> one, so it's PCIe-2.0. Clover is currently lacking in CL compliance at
> this time.
>
> So, I
uble-checked that clinfo and piglit's cl-program-tester ran and could
execute a simple kernel (tests/cl/program/execute/builtin/geometric/
length.cl), so I'd say that this is:
Tested-By: Aaron Watry
And yes, I agree that we should remove the amdgpu dependency from
libamd_common (or at least
clinfo no longer reports my discrete GCN card as unified memory
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/device.cpp | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 5 +
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 7
t/conformance/api/min_max_mem_alloc_size,
OpenCL CTS test/conformance/api/min_max_constant_buffer_size
Signed-off-by: Aaron Watry
---
src/gallium/drivers/radeon/r600_pipe_common.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pip
This is a combination of patches from Jan, Emil, and myself.
The general idea is that we can remove the r600g driver dependency on
the amdgpu drm when OpenCL isn't being built.
I've elected to add a configure-time dependency on libdrm_amdgpu if
CL is enabled at this point. The libamd_common libr
gi?id=101189
Signed-off-by: Emil Velikov
Signed-off-by: Aaron Watry
---
src/amd/common/ac_gpu_info.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/amd/common/ac_gpu_info.h b/src/amd/common/ac_gpu_info.h
index 3f7ade1a0b..4523431cb3 100644
--- a/src/amd/common/ac_gpu_info.h
+++
From: Emil Velikov
The file was introduced to track which LLVM revision was required, yet
that has quickly gone out of shape.
It has seen no updates since 2013.
Cc: Nicolai Hähnle
Cc: Marek Olšák
Signed-off-by: Emil Velikov
Reviewed-by: Aaron Watry
---
src/gallium/drivers/radeon
From: Jan Vesely
Signed-off-by: Jan Vesely
Reviewed-by: Aaron Watry
---
configure.ac| 3 ++-
src/gallium/drivers/r600/Android.mk | 5 -
src/gallium/drivers/r600/Automake.inc | 2 +-
src/gallium/targets/pipe-loader/Makefile.am | 2 +-
4 files
Otherwise r600g will fail to build when the amdgpu drm library is missing
Signed-off-by: Aaron Watry
---
configure.ac | 8
1 file changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index e0996a0004..d1c0814782 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2428,6
n't wait for other Rbs.
>
> Thanks,
> Marek
>
> On Mon, Jun 5, 2017 at 10:31 PM, Aaron Watry wrote:
> > From: Emil Velikov
> >
> > The file was introduced to track which LLVM revision was required, yet
> > that has quickly gone out of shape.
> >
> >
On Mon, Jun 5, 2017 at 5:31 PM, Jan Vesely wrote:
> On Mon, 2017-06-05 at 15:31 -0500, Aaron Watry wrote:
> > From: Jan Vesely
> >
> > Signed-off-by: Jan Vesely
> > Reviewed-by: Aaron Watry
>
> I think Emil preferred v2, with comments and split android ch
This will be used in the next commit to conditionally include amdgpu.h
in ac_gpu_info.h
Signed-off-by: Aaron Watry
Cc: Jan Vesely
Cc: Emil Velikov
---
This worked earlier because I had an intermediate step where I had added
a HAVE_AMD_DRIVERS define elsewhere and didn't git clean b
On Mon, Jun 5, 2017, 3:08 PM Marek Olšák wrote:
> Hi Aaron,
>
> Can you make the change in radeon_drm_winsys.c instead?
>
I'll give it a shot.
--Aaron
> Thanks,
> Marek
>
> On Mon, Jun 5, 2017 at 2:32 AM, Aaron Watry wrote:
> > The CL CTS queries the max
On Tue, Jun 6, 2017 at 8:51 AM, Emil Velikov wrote:
>
> On 5 June 2017 at 21:31, Aaron Watry wrote:
> > Otherwise r600g will fail to build when the amdgpu drm library is missing
> >
> And the code that pulls amdgpu is not used by r600g, which makes this
> misplaced duck
ws->info.max_alloc_size = MIN2(ws->info.max_alloc_size, 256*1024*1024);
--Aaron
>
> Thanks,
> Marek
>
> On Mon, Jun 5, 2017 at 2:32 AM, Aaron Watry wrote:
>> The CL CTS queries the max allocation size, and then attempts to
>> allocate buffers of that si
On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer wrote:
> On 08/06/17 03:42 AM, Marek Olšák wrote:
>> On Wed, Jun 7, 2017 at 4:10 PM, Aaron Watry wrote:
>>> On Mon, Jun 5, 2017 at 3:07 PM, Marek Olšák wrote:
>>>>
>>>> Can you make the change in radeon_dr
t; header = cso->prog;
> code = cso->prog + sizeof(struct pipe_llvm_program_header);
> - radeon_shader_binary_init(&shader->binary);
> - ac_elf_read(code, header->num_bytes, &shader->binary);
> + r600_shader_binary_init(&shader-
On Wed, Jun 7, 2017 at 11:12 PM, Aaron Watry wrote:
> On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer wrote:
>> On 08/06/17 03:42 AM, Marek Olšák wrote:
>>> On Wed, Jun 7, 2017 at 4:10 PM, Aaron Watry wrote:
>>>> On Mon, Jun 5, 2017 at 3:07 PM, Marek Olšák wrote
On Fri, Jun 9, 2017 at 12:36 PM, Jan Vesely wrote:
> On Fri, 2017-06-09 at 10:12 -0500, Aaron Watry wrote:
>> On Fri, Jun 9, 2017 at 8:20 AM, Jan Vesely wrote:
>> > This is a verbatim copy of the code. The functions can be cleaned up since
>> > r600 does not use
Humble ping for this one.
--Aaron
On Sun, Jun 4, 2017 at 7:32 PM, Aaron Watry wrote:
> clinfo no longer reports my discrete GCN card as unified memory
>
> Signed-off-by: Aaron Watry
> ---
> src/gallium/state_trackers/clover/api/device.cpp | 2 +-
> src/gallium/state_tr
Looks like Mark beat me to reporting this one (was still bisecting
when this patch was sent).
Tested-by: Aaron Watry
On Wed, Jun 14, 2017 at 11:08 AM, Samuel Pitoiset
wrote:
> Fixes: 5f249b9f05e ("mapi: add GL_ARB_bindless_texture entry points")
> Reported-by: Mark Janes
re, some applications expect the library to provide
> annotated/versioned symbols.
>
> https://lists.freedesktop.org/archives/mesa-dev/2017-September/171093.html
>
> *Fedora, Suse, Arch, Debian, Ubuntu, FreeBSD use the ICD
> Gentoo manages the conflicting files via eselect.
>
LLVM dependency when that state tracker is enabled, as well...
I did end up having to do some mild rebasing of this patch on top of
current master, but it was pretty trivial.
That being said, this patch seems to be working as intended, so you can add:
Tested-by: Aaron Watry
If you want, I can di
On Wed, 2017-11-01 at 15:49 -0700, Dylan Baker wrote:
> ---
> meson.build | 40 -
> meson_options.txt| 13 +
> src/gallium/meson.build | 7 ++-
> src/gallium/state_trackers/vdpau/meson.build | 32 +++
On Wed, 2017-11-01 at 15:49 -0700, Dylan Baker wrote:
> ---
> meson.build | 35 +-
> meson_options.txt | 13 ++
> src/gallium/meson.build | 7 ++-
> src/gallium/state_trackers/va/meson.build | 39 +
Both this and the va state tracker seem to just install a
libgallium*.so file, but don't actually install the megadriver-esque
links for the hardware-specific driver (e.g. radeonsi_drv_video.so and
libvdpau_radeonsi*).
When I copy the VA driver over my old auto-tools one, I get a libva
initializat
Fixes: OpenCL CTS test/conformance/buffers/buffer_copy
Signed-off-by: Aaron Watry
CC: Francisco Jerez
---
src/gallium/state_trackers/clover/core/memory.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/core/memory.cpp
b/src/gallium
The first patch is one I've been sitting on for a few weeks while
I've tried to chase down other issues with clover/llvm/libclc. It
fixes at least one CTS test that I know of for CL 1.2.
The other 4 patches move the device version declaration to core/device
and then use that along with the -cl-std
The device version is the maximum CL version that the device supports.
Eventually, this will query the pipe_driver itself, but for now move it
a bit closer to its eventual destination.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/device.cpp | 4 ++--
src/gallium
We'll be using it to select the default language version soon.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/core/program.cpp| 6 --
src/gallium/state_trackers/clover/llvm/invocation.cpp | 6 +-
src/gallium/state_trackers/clover/llvm/invocation.hpp | 2 ++
3
According to section 5.8.4.5 of the 2.0 spec, the CL C version is chosen by:
1) If you have -cl-std=CL1.1+ use the version specified
2) If not, use the highest 1.x version that the device supports
Curiously, there is no valid value for -cl-std=CL1.0
Signed-off-by: Aaron Watry
Base it on the active language version
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm
On Sat, Jul 22, 2017 at 2:59 PM, Jan Vesely wrote:
> On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
>> Base it on the active language version
>>
>> Signed-off-by: Aaron Watry
>> ---
>> src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
>&
On Mon, Jul 24, 2017 at 9:41 PM, Aaron Watry wrote:
> On Sat, Jul 22, 2017 at 2:59 PM, Jan Vesely wrote:
>> On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
>>> Base it on the active language version
>>>
>>> Signed-off-by: Aaron Watry
>>> --
I've dropped the first patch of the previous series for now. I'm not
withdrawing it completely, just going to see if there's anything about
the user_ptr stuff that could have been causing the issue instead, and
if I'm using too big a hammer in this patch. If I convince myself of its
correctness, it
The device version is the maximum CL version that the device supports.
Eventually, this will be based on the features/extensions of the actual
device, but for now move it a bit closer to its eventual destination.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/device.cpp
device_version and device_clc_version are not necessarily the same for
devices that support CL 1.0, but have a 1.1 compiler and the necessary
extensions.
CC: Jan Vesey
---
src/gallium/state_trackers/clover/api/device.cpp | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 5 +
src/g
According to section 5.8.4.5 of the 2.0 spec, the CL C version is chosen by:
1) If you have -cl-std=CL1.1+ use the version specified
2) If not, use the highest 1.x version that the device supports
Curiously, there is no valid value for -cl-std=CL1.0
Signed-off-by: Aaron Watry
Cc: Pierre
We'll be using it to select the default language version soon.
Signed-off-by: Aaron Watry
Cc: Pierre Moreau
Cc: Jan Vesely
v2: (Pierre) Move changes to create_compiler_instance invocation to correct
patch to prevent temporary build breakage.
(Jan) Use device_clc_version inste
Signed-off-by: Aaron Watry
CC: Jan Vesely
v2: base it on the device version
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover
Signed-off-by: Aaron Watry
Cc: Pierre Moreau
---
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 16966bedb3
We'll need to be able to detect device version to define the appropriate
__OPENCL_VERSION__ header.
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/c
Copying the individual fields from the device when compiling/linking
will lead to an unnecessarily large number of fields getting passed
around.
Signed-off-by: Aaron Watry
Cc: Jan Vesey
---
src/gallium/state_trackers/clover/core/program.cpp | 9 +++--
.../state_trackers/clover/llvm
What's here is:
Reviewed-By: Aaron Watry
That being said, are clEnqueueMapBuffer/clEnqueueMapImage still
affected or are those always done as blocking operations and my c++ is
weak?
--Aaron
On Fri, Jul 28, 2017 at 10:36 PM, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
/
On Sat, Jul 22, 2017 at 2:27 PM, Jan Vesely wrote:
> On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
>> Fixes: OpenCL CTS test/conformance/buffers/buffer_copy
>
> Similar patch was pushed in 2013:
> 56647c5d8f8e60269f0a3277e3caa7ee57d1fe6a
> "clove
201 - 300 of 392 matches
Mail list logo
