similar to: Updates

On 18/09/2019 13:12, Jerry Geis wrote: > I did yum -y update --exclude=vulkan*; then rebooted > > When I do yum check-updates I get this: (which I expect) > > vulkan.x86_64 > 1.1.97.0-1.el7 base > vulkan-filesystem.noarch > 1.1.97.0-1.el7 base > > When I do the yum -y update I get

I note that there was a talk recently at EuroLLVM SPIR-V and LLVM about and so I want to get this message out soon so as to avoid duplicated effort. I have an up to date backend for SPIR-V on an up to date fork (~2-3 weeks behind) of LLVM, transplanted and “modernised” from Khronos’ SPIRV-LLVM that I plan on integrating into LLVM trunk. While it is usable in it’s current form there are several

> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V

I agree that having the conversion live as part of LLVM is the best option going forward. libclc is an library implementation of the OpenCL builtins and I think its fine for that aspect of the converter, i.e. consumption of SPIR-V into LLVM IR in preparation for code generation by LLVM by its various backends as a library to link the generated code to, to live in an external repo. This is fine

2015-05-16 6:42 GMT+01:00 Chris Lattner <clattner at apple.com>: > > > On May 15, 2015, at 9:53 AM, Chris Bieneman <beanz at apple.com> wrote: > > > > +1 to lib/Target/SPIRV/(Reader|Writer) > > > > I really like this idea. I’ve talked with some people on both the LLVM and Khronos sides and I really think adding SPIR-V support to LLVM as an optional

On Fri, May 15, 2015 at 11:50 AM, David Chisnall < David.Chisnall at cl.cam.ac.uk> wrote: > On 15 May 2015, at 17:53, Chris Bieneman <beanz at apple.com> wrote: > > > > +1 to lib/Target/SPIRV/(Reader|Writer) > > > > I really like this idea. I’ve talked with some people on both the LLVM > and Khronos sides and I really think adding SPIR-V support to LLVM

On 02/21/2018 10:58 AM, Nicholas Wilson wrote: > I agree that having the conversion live as part of LLVM is the best option going forward. > > libclc is an library implementation of the OpenCL builtins and I think its fine for that aspect of the converter, > i.e. consumption of SPIR-V into LLVM IR in preparation for code generation by LLVM by its various backends as a library > to

On 27 Feb 2018, at 9:07 pm, Anastasia Stulova via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > SPIR-V does not have to be a part of LLVM for you to do this. You can add > the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) > that uses the external tool to translate LLVM IR to SPIR-V. Ok. I guess

> It's important to demonstrate that there is a developer community backing > the tool and that it won't be abandoned if it is added as an llvm > sub-project. > > -Tom Just to complete the picture, this is an initiative from within Khronos Group to unify our effort to make this available as an LLVM component. A number of companies have been involved in the original

It is just a header file. All source code is under lib/Target/SPIRV since they really belong there. Those who want to use the conversion functionality just need to link with the SPIRV target library. Any suggestion about a better location for the header file? Thanks. Sam From: Chris Bieneman [mailto:beanz at apple.com] Sent: Wednesday, June 17, 2015 2:31 PM To: Liu, Yaxun (Sam) Cc: llvmdev at

Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2.

Hi Mehdi, Thank you for your comments. My comments are below. Sam From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Wednesday, June 17, 2015 12:43 PM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target Hi Liu, Thanks for the detailed proposal. On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at

Hi, for a few months already I have been asking around for opinions on how people could best work together on Khronos' SPIR-V <-> LLVM-IR converter and some consensus seems to have formed. Most of the people I talked to favored having the converter become an external tool within the LLVM project, similar to libclc. I think that the LLVM project's processes, infrastructure and

> SPIR-V does not have to be a part of LLVM for you to do this. You can add > the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) > that uses the external tool to translate LLVM IR to SPIR-V. Ok. I guess if Clang community accepts this way, it would be better to set up the SPIRV converter as a tool of LLVM. So the question is are there any

On 2018-02-21 — 14:55, Tom Stellard via llvm-dev wrote: > On 02/21/2018 12:15 AM, Tomeu Vizoso via llvm-dev wrote: > > Hi, > > > > for a few months already I have been asking around for opinions on how > > people could best work together on Khronos' SPIR-V <-> LLVM-IR converter > > and some consensus seems to have formed. > > > > Most of the

On 1 May 2017, at 11:53 pm, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > First of all you may want to review the thread from a few years ago about putting a SPIR-V target into LLVM: > http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html Thanks I will take a look. > The fact that the SPIR-V

On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: > On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>> Right, what I was trying to say is that there are more benefits from >>> having this not be a target than there is from having it be a target. >> Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t

From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Thursday, June 18, 2015 11:24 AM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Hi Mehdi, Thank you for your comments. My comments are below. Sam From:

Yet another implementation of the backend, heh. I’d just started in earnest writing a tablegen based one, with the main goal of fixing the intrinsics to actually be intrinsics. I think it would be a good idea to join forces with the folk at KhronosGroup and consolidate the work done for inclusion into LLVM. Nic > On 17 Jul 2017, at 9:55 pm, Neil Henning via llvm-dev <llvm-dev at

>Right, what I was trying to say is that there are more benefits from >having this not be a target than there is from having it be a target. Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed