Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"
Am 01.10.2016 um 00:06 schrieb Marek Olšák: On Fri, Sep 30, 2016 at 11:23 PM, Dave Airlie wrote: On 1 October 2016 at 06:11, Marek Olšák wrote: On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin wrote: So is this getting pushed, or should I push my "don't build vdpau for nouveau" patch? Please wait. Christian, your commit says it fixes a radeonsi issue, but Ilia says it breaks nouveau. Can we do something to accommodate both drivers? Should we add a CAP for whether to use a linear layout for output surfaces? I think we need a flag that isn't SHARED/LINEAR that is more SHARED_OTHER_GPU. That would be useless. Most OpenGL textures can be shared with other GPUs and processes via the EGL dmabuf extensions. Relying on PIPE_BIND_SHARED is a bug by itself and no driver should do that. Yeah, completely agree. To answer the original question the comment in the patch was about an issue with sharing tiling information, but I think that is long fixed by now. Anyway somebody needs to test this, but I don't have time right now. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Error when trying to compile RADV
Hello, I decided to try out the work-in-progress AMD driver with Vulkan support: https://github.com/airlied/mesa/tree/semi-interesting But when I try to compile the source, it fails -- see the log: http://pastebin.com/1nCQYCEF Is this a common problem with the official mesa3d repo aswell, or is it RADV-specific? How can I resolve this? Thank you, Jakub "Limeth" Hlusička ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error when trying to compile RADV
Hello,
I might not be an expert, but it seems that the build system failed to
locate radeon_llvm_check function. I heard somewhere on this list that
there is currently a problem with it being used before it's defined. I
think you will need to modify configure.ac and move it from line 2323
to, e.g. 1660 (the whole function, so from "radeon_llvm_check() {" to
the "}" line).
Regards,
Gustaw
2016-10-01 14:23 GMT+02:00 Limeth :
> Hello,
> I decided to try out the work-in-progress AMD driver with Vulkan support:
> https://github.com/airlied/mesa/tree/semi-interesting
> But when I try to compile the source, it fails -- see the log:
> http://pastebin.com/1nCQYCEF
>
> Is this a common problem with the official mesa3d repo aswell, or is it
> RADV-specific? How can I resolve this?
>
> Thank you,
> Jakub "Limeth" Hlusička
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] clover: add GetKernelArgInfo (CL 1.2)
---
src/gallium/state_trackers/clover/api/kernel.cpp | 47 --
src/gallium/state_trackers/clover/core/kernel.cpp | 6 +++
src/gallium/state_trackers/clover/core/kernel.hpp | 1 +
src/gallium/state_trackers/clover/core/module.hpp | 19 +--
.../state_trackers/clover/llvm/codegen/common.cpp | 58 +-
.../state_trackers/clover/llvm/metadata.hpp| 16 ++
.../state_trackers/clover/tgsi/compiler.cpp| 2 +-
7 files changed, 141 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/kernel.cpp
b/src/gallium/state_trackers/clover/api/kernel.cpp
index 73ba34a..13cfc08 100644
--- a/src/gallium/state_trackers/clover/api/kernel.cpp
+++ b/src/gallium/state_trackers/clover/api/kernel.cpp
@@ -192,9 +192,50 @@ clGetKernelWorkGroupInfo(cl_kernel d_kern, cl_device_id
d_dev,
CLOVER_API cl_int
clGetKernelArgInfo(cl_kernel d_kern,
cl_uint idx, cl_kernel_arg_info param,
- size_t size, void *r_buf, size_t *r_size) {
- CLOVER_NOT_SUPPORTED_UNTIL("1.2");
- return CL_KERNEL_ARG_INFO_NOT_AVAILABLE;
+ size_t size, void *r_buf, size_t *r_size) try {
+ property_buffer buf { r_buf, size, r_size };
+ const auto &kern = obj(d_kern);
+ const auto args_info = kern.args_info();
+
+ if (args_info.size() == 0)
+ throw error(CL_KERNEL_ARG_INFO_NOT_AVAILABLE);
+
+ if (idx >= args_info.size())
+ throw error(CL_INVALID_ARG_INDEX);
+
+ const auto &info = args_info[idx];
+
+ switch (param) {
+ case CL_KERNEL_ARG_ADDRESS_QUALIFIER:
+ buf.as_scalar() =
+ info.address_qualifier;
+ break;
+
+ case CL_KERNEL_ARG_ACCESS_QUALIFIER:
+ buf.as_scalar() =
+ info.access_qualifier;
+ break;
+
+ case CL_KERNEL_ARG_TYPE_NAME:
+ buf.as_string() = info.type_name;
+ break;
+
+ case CL_KERNEL_ARG_TYPE_QUALIFIER:
+ buf.as_scalar() = info.type_qualifier;
+ break;
+
+ case CL_KERNEL_ARG_NAME:
+ buf.as_string() = info.arg_name;
+ break;
+
+ default:
+ throw error(CL_INVALID_VALUE);
+ }
+
+ return CL_SUCCESS;
+
+} catch (error &e) {
+ return e.get();
}
namespace {
diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp
b/src/gallium/state_trackers/clover/core/kernel.cpp
index 962f555..18dcd5c 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -140,6 +140,12 @@ kernel::args() const {
return map(derefs(), _args);
}
+std::vector
+kernel::args_info() const {
+ const auto &syms = program().symbols();
+ return find(name_equals(_name), syms).args_info;
+}
+
const module &
kernel::module(const command_queue &q) const {
return program().build(q.device()).binary;
diff --git a/src/gallium/state_trackers/clover/core/kernel.hpp
b/src/gallium/state_trackers/clover/core/kernel.hpp
index 4ba6ff4..aae51bc 100644
--- a/src/gallium/state_trackers/clover/core/kernel.hpp
+++ b/src/gallium/state_trackers/clover/core/kernel.hpp
@@ -134,6 +134,7 @@ namespace clover {
argument_range args();
const_argument_range args() const;
+ std::vector args_info() const;
const intrusive_ref program;
diff --git a/src/gallium/state_trackers/clover/core/module.hpp
b/src/gallium/state_trackers/clover/core/module.hpp
index 5db0548..5ce9492 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -102,16 +102,29 @@ namespace clover {
semantic semantic;
};
+ struct argument_info {
+ argument_info() { }
+
+ uint32_t address_qualifier;
+ uint32_t access_qualifier;
+ std::string type_name;
+ uint32_t type_qualifier;
+ std::string arg_name;
+ };
+
struct symbol {
symbol(const std::string &name, resource_id section,
-size_t offset, const std::vector &args) :
-name(name), section(section), offset(offset), args(args) { }
- symbol() : name(), section(0), offset(0), args() { }
+size_t offset, const std::vector &args,
+const std::vector &args_info) :
+name(name), section(section), offset(offset),
+args(args), args_info(args_info) { }
+ symbol() : name(), section(0), offset(0), args(), args_info() { }
std::string name;
resource_id section;
size_t offset;
std::vector args;
+ std::vector args_info;
};
void serialize(std::ostream &os) const;
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index 834b06a..07f45f9 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/co
Re: [Mesa-dev] [PATCH] glsl: add missing headers to blob.h
Rb
On Sep 30, 2016 6:45 PM, "Timothy Arceri"
wrote:
> ---
> src/compiler/glsl/blob.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/glsl/blob.h b/src/compiler/glsl/blob.h
> index ec903ec..0765bf3 100644
> --- a/src/compiler/glsl/blob.h
> +++ b/src/compiler/glsl/blob.h
> @@ -29,6 +29,8 @@
> extern "C" {
> #endif
>
> +#include
> +#include
> #include
>
> /* The blob functions implement a simple, low-level API for serializing
> and
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error when trying to compile RADV
Hi, Do you have LLVM development packages installed? It seems configure can't find llvm-config and the header that can't be found is in the standard include path, at least for archlinux (i.e. /usr/include/llvm-c/TargetMachine.h). radv needs LLVM 3.9 development packages or newer. The issue Gustaw referred to is probably the cause of configure not giving an error about it. If you want to be sure this is handled right, also enable radeonsi to be build. Yours sincerely, Bas Nieuwenhuizen On Sat, Oct 1, 2016 at 2:23 PM, Limeth wrote: > Hello, > I decided to try out the work-in-progress AMD driver with Vulkan support: > https://github.com/airlied/mesa/tree/semi-interesting > But when I try to compile the source, it fails -- see the log: > http://pastebin.com/1nCQYCEF > > Is this a common problem with the official mesa3d repo aswell, or is it > RADV-specific? How can I resolve this? > > Thank you, > Jakub "Limeth" Hlusička > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error when trying to compile RADV
I have found out that the llvm-3.9 installation directory in Ubuntu is not as you said and ended up creating symlinks to it: ``` sudo ln -s /usr/include/llvm-3.9/llvm/ /usr/include/llvm sudo ln -s /usr/include/llvm-c-3.9/llvm-c/ /usr/include/llvm-c ``` Now I seem to be getting a different error: ``` ac_llvm_util.c: In function ‘ac_init_llvm_target’: ac_llvm_util.c:13:2: error: implicit declaration of function ‘LLVMInitializeR600TargetInfo’ [-Werror=implicit-function-declaration] LLVMInitializeR600TargetInfo(); ^ ac_llvm_util.c:14:2: error: implicit declaration of function ‘LLVMInitializeR600Target’ [-Werror=implicit-function-declaration] LLVMInitializeR600Target(); ^ ac_llvm_util.c:15:2: error: implicit declaration of function ‘LLVMInitializeR600TargetMC’ [-Werror=implicit-function-declaration] LLVMInitializeR600TargetMC(); ^ ac_llvm_util.c:16:2: error: implicit declaration of function ‘LLVMInitializeR600AsmPrinter’ [-Werror=implicit-function-declaration] LLVMInitializeR600AsmPrinter(); ^ cc1: some warnings being treated as errors ``` Full log: http://pastebin.com/QgyQdX0r After further investigation, I've found that this error resides in RADV-specific source code; now I'm on my own. I will proceed to revert to older, working commits on that branch. Thank you for the help everyone, much appreciated! Jakub "Limeth" Hlusička On So, říj 1, 2016 at 5:29 , Bas Nieuwenhuizen wrote: Hi, Do you have LLVM development packages installed? It seems configure can't find llvm-config and the header that can't be found is in the standard include path, at least for archlinux (i.e. /usr/include/llvm-c/TargetMachine.h). radv needs LLVM 3.9 development packages or newer. The issue Gustaw referred to is probably the cause of configure not giving an error about it. If you want to be sure this is handled right, also enable radeonsi to be build. Yours sincerely, Bas Nieuwenhuizen On Sat, Oct 1, 2016 at 2:23 PM, Limeth wrote: Hello, I decided to try out the work-in-progress AMD driver with Vulkan support: https://github.com/airlied/mesa/tree/semi-interesting But when I try to compile the source, it fails -- see the log: http://pastebin.com/1nCQYCEF Is this a common problem with the official mesa3d repo aswell, or is it RADV-specific? How can I resolve this? Thank you, Jakub "Limeth" Hlusička ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] clover: add missing clGetDeviceInfo CL1.2 queries
---
src/gallium/state_trackers/clover/api/device.cpp | 23 +++
src/gallium/state_trackers/clover/core/device.cpp | 10 ++
src/gallium/state_trackers/clover/core/device.hpp | 2 ++
3 files changed, 35 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src/gallium/state_trackers/clover/api/device.cpp
index f7bd61b..a80ca46 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -184,6 +184,14 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
buf.as_scalar() = 1 << dev.max_image_levels_3d();
break;
+ case CL_DEVICE_IMAGE_MAX_BUFFER_SIZE:
+ buf.as_scalar() = dev.max_image_buffer_size();
+ break;
+
+ case CL_DEVICE_IMAGE_MAX_ARRAY_SIZE:
+ buf.as_scalar() = dev.max_image_array_number();
+ break;
+
case CL_DEVICE_IMAGE_SUPPORT:
buf.as_scalar() = dev.image_support();
break;
@@ -273,6 +281,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
case CL_DEVICE_AVAILABLE:
case CL_DEVICE_COMPILER_AVAILABLE:
+ case CL_DEVICE_LINKER_AVAILABLE:
buf.as_scalar() = CL_TRUE;
break;
@@ -284,6 +293,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
buf.as_scalar() = CL_QUEUE_PROFILING_ENABLE;
break;
+ case CL_DEVICE_BUILT_IN_KERNELS:
+ buf.as_string() = "";
+ break;
+
case CL_DEVICE_NAME:
buf.as_string() = dev.device_name();
break;
@@ -358,6 +371,16 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
buf.as_string() = "OpenCL C 1.1 ";
break;
+ case CL_DEVICE_PRINTF_BUFFER_SIZE:
+ // Per the spec, the minimum value for the FULL profile is 1 MB.
+ // However, clover is not ready yet to support it
+ buf.as_scalar() = 0 /* 1024 */;
+ break;
+
+ case CL_DEVICE_PREFERRED_INTEROP_USER_SYNC:
+ buf.as_scalar() = CL_TRUE;
+ break;
+
case CL_DEVICE_PARENT_DEVICE:
buf.as_scalar() = NULL;
break;
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 8825f99..8f1c1da 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -98,6 +98,11 @@ device::max_images_write() const {
return PIPE_MAX_SHADER_IMAGES;
}
+size_t
+device::max_image_buffer_size() const {
+ return pipe->get_param(pipe, PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE);
+}
+
cl_uint
device::max_image_levels_2d() const {
return pipe->get_param(pipe, PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
@@ -108,6 +113,11 @@ device::max_image_levels_3d() const {
return pipe->get_param(pipe, PIPE_CAP_MAX_TEXTURE_3D_LEVELS);
}
+size_t
+device::max_image_array_number() const {
+ return pipe->get_param(pipe, PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS);
+}
+
cl_uint
device::max_samplers() const {
return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
diff --git a/src/gallium/state_trackers/clover/core/device.hpp
b/src/gallium/state_trackers/clover/core/device.hpp
index 6cf6c7f..94a61d1 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -51,8 +51,10 @@ namespace clover {
cl_uint vendor_id() const;
size_t max_images_read() const;
size_t max_images_write() const;
+ size_t max_image_buffer_size() const;
cl_uint max_image_levels_2d() const;
cl_uint max_image_levels_3d() const;
+ size_t max_image_array_number() const;
cl_uint max_samplers() const;
cl_ulong max_mem_global() const;
cl_ulong max_mem_local() const;
--
2.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/2] Add support for some of the missing CL1.2 queries
Updated serie, please review. Serge Martin (2): clover: add CL_PROGRAM_BINARY_TYPE support (CL1.2) clover: add missing clGetDeviceInfo CL1.2 queries src/gallium/state_trackers/clover/api/device.cpp | 23 ++ src/gallium/state_trackers/clover/api/program.cpp | 5 + src/gallium/state_trackers/clover/core/device.cpp | 10 ++ src/gallium/state_trackers/clover/core/device.hpp | 2 ++ src/gallium/state_trackers/clover/core/module.cpp | 1 + src/gallium/state_trackers/clover/core/module.hpp | 5 + src/gallium/state_trackers/clover/llvm/codegen.hpp | 3 +++ .../state_trackers/clover/llvm/codegen/bitcode.cpp | 11 +-- .../state_trackers/clover/llvm/codegen/common.cpp | 2 +- .../state_trackers/clover/llvm/invocation.cpp | 2 +- .../state_trackers/clover/tgsi/compiler.cpp| 2 +- 11 files changed, 61 insertions(+), 5 deletions(-) -- 2.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] clover: add CL_PROGRAM_BINARY_TYPE support (CL1.2)
CL_PROGRAM_BINARY_TYPE have been added to clGetProgramBuildInfo in CL1.2
---
src/gallium/state_trackers/clover/api/program.cpp | 5 +
src/gallium/state_trackers/clover/core/module.cpp | 1 +
src/gallium/state_trackers/clover/core/module.hpp | 5 +
src/gallium/state_trackers/clover/llvm/codegen.hpp | 3 +++
src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp | 11 +--
src/gallium/state_trackers/clover/llvm/codegen/common.cpp | 2 +-
src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
src/gallium/state_trackers/clover/tgsi/compiler.cpp| 2 +-
8 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/api/program.cpp
index c3f9cb9..543eeb6 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -401,6 +401,11 @@ clGetProgramBuildInfo(cl_program d_prog, cl_device_id
d_dev,
buf.as_string() = prog.build(dev).log;
break;
+ case CL_PROGRAM_BINARY_TYPE:
+ buf.as_scalar() =
+ prog.build(dev).binary.binary_type;
+ break;
+
default:
throw error(CL_INVALID_VALUE);
}
diff --git a/src/gallium/state_trackers/clover/core/module.cpp
b/src/gallium/state_trackers/clover/core/module.cpp
index a6c5b98..cc24a2b 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -202,6 +202,7 @@ namespace {
template
static void
proc(S &s, QT &x) {
+ _proc(s, x.binary_type);
_proc(s, x.syms);
_proc(s, x.secs);
}
diff --git a/src/gallium/state_trackers/clover/core/module.hpp
b/src/gallium/state_trackers/clover/core/module.hpp
index 5db0548..bcf2a29 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -114,10 +114,15 @@ namespace clover {
std::vector args;
};
+ module() : binary_type(0), syms(), secs() { }
+ module(size_t binary_type) :
+ binary_type(binary_type), syms(), secs() { }
+
void serialize(std::ostream &os) const;
static module deserialize(std::istream &is);
size_t size() const;
+ size_t binary_type;
std::vector syms;
std::vector secs;
};
diff --git a/src/gallium/state_trackers/clover/llvm/codegen.hpp
b/src/gallium/state_trackers/clover/llvm/codegen.hpp
index e0e9901..49de79d 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen.hpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen.hpp
@@ -46,6 +46,9 @@ namespace clover {
print_module_bitcode(const ::llvm::Module &mod);
module
+ build_module_compiled(const ::llvm::Module &mod);
+
+ module
build_module_library(const ::llvm::Module &mod);
std::unique_ptr<::llvm::Module>
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 658cce9..c75514b 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -80,13 +80,20 @@ clover::llvm::print_module_bitcode(const ::llvm::Module
&mod) {
}
module
-clover::llvm::build_module_library(const ::llvm::Module &mod) {
- module m;
+clover::llvm::build_module_compiled(const ::llvm::Module &mod) {
+ module m(CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT);
const auto code = emit_code(mod);
m.secs.emplace_back(0, module::section::text, code.size(), code);
return m;
}
+module
+clover::llvm::build_module_library(const ::llvm::Module &mod) {
+ module m = build_module_compiled(mod);
+ m.binary_type = CL_PROGRAM_BINARY_TYPE_LIBRARY;
+ return m;
+}
+
std::unique_ptr<::llvm::Module>
clover::llvm::parse_module_library(const module &m, ::llvm::LLVMContext &ctx,
std::string &r_log) {
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index 834b06a..bd7207f 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -195,7 +195,7 @@ clover::llvm::build_module_common(const Module &mod,
const std::map &offsets,
const clang::CompilerInstance &c) {
- module m;
+ module m(CL_PROGRAM_BINARY_TYPE_EXECUTABLE);
for (const auto &name : map(std::mem_fn(&Function::getName),
get_kernels(mod))) {
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index b5e8b52..fe10b78 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clov
Re: [Mesa-dev] [PATCH] clover: clGetExtensionFunctionAddressForPlatform
On Sunday 27 September 2015 11:15:14 Serge Martin wrote:
> add clGetExtensionFunctionAddressForPlatform (CL 1.2)
ping (one year reminder :p )
> ---
> src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
> src/gallium/state_trackers/clover/api/dispatch.hpp | 4
> src/gallium/state_trackers/clover/api/platform.cpp | 16
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp
> b/src/gallium/state_trackers/clover/api/dispatch.cpp index f10babe..8f4cfdc
> 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.cpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
> @@ -131,7 +131,7 @@ namespace clover {
>clEnqueueMigrateMemObjects,
>clEnqueueMarkerWithWaitList,
>clEnqueueBarrierWithWaitList,
> - NULL, // clGetExtensionFunctionAddressForPlatform
> + GetExtensionFunctionAddressForPlatform,
>NULL, // clCreateFromGLTexture
>NULL, // clGetDeviceIDsFromD3D11KHR
>NULL, // clCreateFromD3D11BufferKHR
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp
> b/src/gallium/state_trackers/clover/api/dispatch.hpp index 7f62282..0ec1b51
> 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
> @@ -777,6 +777,10 @@ namespace clover {
> void *
> GetExtensionFunctionAddress(const char *p_name);
>
> + void *
> + GetExtensionFunctionAddressForPlatform(cl_platform_id d_platform,
> + const char *p_name);
> +
> cl_int
> IcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
> cl_uint *rnum_platforms);
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
> b/src/gallium/state_trackers/clover/api/platform.cpp index cf71593..2bde194
> 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -87,6 +87,16 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
> cl_platform_info param, }
>
> void *
> +clover::GetExtensionFunctionAddressForPlatform(cl_platform_id d_platform,
> + const char *p_name) try {
> + obj(d_platform);
> + return GetExtensionFunctionAddress(p_name);
> +
> +} catch (error &e) {
> + return NULL;
> +}
> +
> +void *
> clover::GetExtensionFunctionAddress(const char *p_name) {
> std::string name { p_name };
>
> @@ -113,6 +123,12 @@ clGetExtensionFunctionAddress(const char *p_name) {
> return GetExtensionFunctionAddress(p_name);
> }
>
> +CLOVER_ICD_API void *
> +clGetExtensionFunctionAddressForPlatform(cl_platform_id d_platform,
> + const char *p_name) {
> + return GetExtensionFunctionAddressForPlatform(d_platform, p_name);
> +}
> +
> CLOVER_ICD_API cl_int
> clIcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
> cl_uint *rnum_platforms) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Proposal of date-based Mesa versioning for 2017
Hi, I propose that we use versioning in the form of "year.quarter". 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following quarters of the year, respectively. 2018 would start with 18.0, then 18.1, 18.2, 18.3. The motivation is that you can easily tell when a specific Mesa version was released with an accuracy of 3 months. That's the only scheme that seems practical to me. Everything else seems arbitrary or random. Opinions? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
I could get behind that. The only other thing that makes sense to me would be to drop minor versoning all together and just have an incrementing integer (with patch releases for stable, of course). The year.quarter scheme is fine with me too. On Sat, Oct 1, 2016 at 12:46 PM, Marek Olšák wrote: > Hi, > > I propose that we use versioning in the form of "year.quarter". > > 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following > quarters of the year, respectively. > 2018 would start with 18.0, then 18.1, 18.2, 18.3. > > The motivation is that you can easily tell when a specific Mesa > version was released with an accuracy of 3 months. > > That's the only scheme that seems practical to me. Everything else > seems arbitrary or random. > > Opinions? > > Marek > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
On 01.10.2016 21:46, Marek Olšák wrote: Hi, I propose that we use versioning in the form of "year.quarter". 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following quarters of the year, respectively. 2018 would start with 18.0, then 18.1, 18.2, 18.3. The motivation is that you can easily tell when a specific Mesa version was released with an accuracy of 3 months. That's the only scheme that seems practical to me. Everything else seems arbitrary or random. Opinions? Why not just use year.month instead, would be more accurate...and releases happen semi random anyway and not after a given time. Greetings, Tobias Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error when trying to compile RADV
I don't think your fix with the symlinks is correct. You've just worked-around one part of the problem (missing include directories) leaving the total lack of detection of llvm alone. Now you lack the HAVE_LLVM define that should be automatically created by the build system if it recognizes llvm correctly. Without it, the source code references the already non-existing R600 target, since it doesn't know which llvm version it deals with. After that you will lack the library references, and maybe other llvm-specific compilation options. Trying to work-around all that seems counterproductive. Do you have the llvm development package (I think it's called llvm-dev or libllvm-dev on ubuntu) installed? It seems that configure cannot find the llvm-config binary. It should probably be in /usr/bin. 2016-10-01 18:44 GMT+02:00 Limeth : > I have found out that the llvm-3.9 installation directory in Ubuntu is not > as you said and ended up creating symlinks to it: > ``` > sudo ln -s /usr/include/llvm-3.9/llvm/ /usr/include/llvm > sudo ln -s /usr/include/llvm-c-3.9/llvm-c/ /usr/include/llvm-c > ``` > > Now I seem to be getting a different error: > ``` > ac_llvm_util.c: In function ‘ac_init_llvm_target’: > ac_llvm_util.c:13:2: error: implicit declaration of function > ‘LLVMInitializeR600TargetInfo’ [-Werror=implicit-function-declaration] > LLVMInitializeR600TargetInfo(); > ^ > ac_llvm_util.c:14:2: error: implicit declaration of function > ‘LLVMInitializeR600Target’ [-Werror=implicit-function-declaration] > LLVMInitializeR600Target(); > ^ > ac_llvm_util.c:15:2: error: implicit declaration of function > ‘LLVMInitializeR600TargetMC’ [-Werror=implicit-function-declaration] > LLVMInitializeR600TargetMC(); > ^ > ac_llvm_util.c:16:2: error: implicit declaration of function > ‘LLVMInitializeR600AsmPrinter’ [-Werror=implicit-function-declaration] > LLVMInitializeR600AsmPrinter(); > ^ > cc1: some warnings being treated as errors > ``` > Full log: http://pastebin.com/QgyQdX0r > > After further investigation, I've found that this error resides in > RADV-specific source code; now I'm on my own. I will proceed to revert to > older, working commits on that branch. > > Thank you for the help everyone, much appreciated! > Jakub "Limeth" Hlusička > > On So, říj 1, 2016 at 5:29 , Bas Nieuwenhuizen > wrote: > > Hi, Do you have LLVM development packages installed? It seems configure > can't find llvm-config and the header that can't be found is in the standard > include path, at least for archlinux (i.e. > /usr/include/llvm-c/TargetMachine.h). radv needs LLVM 3.9 development > packages or newer. The issue Gustaw referred to is probably the cause of > configure not giving an error about it. If you want to be sure this is > handled right, also enable radeonsi to be build. Yours sincerely, Bas > Nieuwenhuizen On Sat, Oct 1, 2016 at 2:23 PM, Limeth > wrote: > > Hello, I decided to try out the work-in-progress AMD driver with Vulkan > support: https://github.com/airlied/mesa/tree/semi-interesting But when I > try to compile the source, it fails -- see the log: > http://pastebin.com/1nCQYCEF Is this a common problem with the official > mesa3d repo aswell, or is it RADV-specific? How can I resolve this? Thank > you, Jakub "Limeth" Hlusička ___ > mesa-dev mailing list mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] nir/spirv: Use a nop intrinsic for tagging the ends of blocks
Bump...
On Thu, Sep 15, 2016 at 9:33 PM, Dave Airlie wrote:
> On 16 September 2016 at 14:16, Jason Ekstrand
> wrote:
> > Previously, we were saving off the last nir_block in a vtn_block before
> > moving on so that we could find the nir_block again when it came time to
> > handle phi sources. Unfortunately, NIR's control flow modification code
> is
> > inconsistent when it comes to how it splits blocks so the block pointer
> we
> > saved off may point to a block somewhere else in the shader by the time
> we
> > get around to handling phi sources. In order to get around this, we
> insert
> > a nop instruction and use that as the logical end of our block. Since
> the
> > control flow manipulation code respects instructions, the nop will keeps
> > its place like any other instruction and we can easily find the end of
> our
> > block when we need it.
> >
> > Signed-off-by: Jason Ekstrand
>
> I'm not sure I'm good enough to review it, but this makes sense after
> I looked through it.
>
> It also fixes vkQuake on radv.
>
> Tested-by: Dave Airlie
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97233
>
> Dave.
>
> > ---
> > src/compiler/spirv/vtn_cfg.c | 6 --
> > src/compiler/spirv/vtn_private.h | 4 ++--
> > 2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
> > index d9096f4..599ed69 100644
> > --- a/src/compiler/spirv/vtn_cfg.c
> > +++ b/src/compiler/spirv/vtn_cfg.c
> > @@ -518,7 +518,7 @@ vtn_handle_phi_second_pass(struct vtn_builder *b,
> SpvOp opcode,
> >struct vtn_block *pred =
> > vtn_value(b, w[i + 1], vtn_value_type_block)->block;
> >
> > - b->nb.cursor = nir_after_block_before_jump(pred->end_block);
> > + b->nb.cursor = nir_after_instr(&pred->end_nop->instr);
> >
> >vtn_local_store(b, src, nir_deref_var_create(b, phi_var));
> > }
> > @@ -576,7 +576,9 @@ vtn_emit_cf_list(struct vtn_builder *b, struct
> list_head *cf_list,
> >
> > vtn_foreach_instruction(b, block_start, block_end, handler);
> >
> > - block->end_block = nir_cursor_current_block(b->nb.cursor);
> > + block->end_nop = nir_intrinsic_instr_create(b->nb.shader,
> > + nir_intrinsic_nop);
> > + nir_builder_instr_insert(&b->nb, &block->end_nop->instr);
> >
> > if ((*block->branch & SpvOpCodeMask) == SpvOpReturnValue) {
> > struct vtn_ssa_value *src = vtn_ssa_value(b,
> block->branch[1]);
> > diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_
> private.h
> > index 7f5444e..6f34f09 100644
> > --- a/src/compiler/spirv/vtn_private.h
> > +++ b/src/compiler/spirv/vtn_private.h
> > @@ -149,8 +149,8 @@ struct vtn_block {
> > /** Points to the switch case started by this block (if any) */
> > struct vtn_case *switch_case;
> >
> > - /** The last block in this SPIR-V block. */
> > - nir_block *end_block;
> > + /** Every block ends in a nop intrinsic so that we can find it again
> */
> > + nir_intrinsic_instr *end_nop;
> > };
> >
> > struct vtn_function {
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 4/4] nir/spirv: add spirv2nir binary to .gitignore
On Sep 26, 2016 3:00 AM, "Eric Engestrom" wrote: > > On Sun, Sep 25, 2016 at 10:49:29AM -0700, Jason Ekstrand wrote: > > I hope you realize that this is the only truly useful change in the series. > > :-). Still, no reason why our silly little helpers shouldn't be correct. > > Yeah, I know :P > I got the Coverity report like everyone and thought we might as well > print real error messages, esp. since asserts are gone in release builds > (but who would use spirv2nir in a release build? ^^) > > > Series is > > > > Reviewed-by: Jason Ekstrand > > Thanks! Can you push it for me? Pushed. Thanks! > Cheers, > Eric > > > > > On Sep 25, 2016 6:50 PM, "Eric Engestrom" wrote: > > > > > Signed-off-by: Eric Engestrom > > > --- > > > src/compiler/.gitignore | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/src/compiler/.gitignore b/src/compiler/.gitignore > > > index c0e6299..c4f17be 100644 > > > --- a/src/compiler/.gitignore > > > +++ b/src/compiler/.gitignore > > > @@ -3,3 +3,4 @@ subtest-cr > > > subtest-cr-lf > > > subtest-lf > > > subtest-lf-cr > > > +spirv2nir > > > -- > > > Cheers, > > > Eric > > > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
On Saturday, October 1, 2016 9:46:45 PM PDT Marek Olšák wrote: > Hi, > > I propose that we use versioning in the form of "year.quarter". > > 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following > quarters of the year, respectively. > 2018 would start with 18.0, then 18.1, 18.2, 18.3. > > The motivation is that you can easily tell when a specific Mesa > version was released with an accuracy of 3 months. > > That's the only scheme that seems practical to me. Everything else > seems arbitrary or random. > > Opinions? > > Marek I like it. We clearly need some kind of new scheme, and date based versions are one of the more sensible ones out there. They fit pretty well with our time-based releases. They make it easy to tell how old people's drivers are. They also avoid the version inflation of "every release is a new major version". One thing that's nice about using quarters is that the versions remain sequential (17.0 -> 17.1 -> 17.2 -> ...) while the usual "month of the release" scheme isn't (17.2 -> 17.5 -> ???). Avoids the "but where's 17.3???" questions. Also means the versions are unaffected by any schedule slips. Another way of thinking about it: the first release of the year gets a major version bump. Otherwise, the minor version increments each release. (Equivalent, but works if we change from quarterly releases to something more or less frequent.) --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
