similar to: [LLVMdev] RFC: R600, a new backend for AMD GPUs

Hi Tom, I have a higher-level question regarding this back-end. If I have an LLVM IR module and run it through this back-end, it seems like the only output option is a binary format. Is this a device binary, or another intermediate format? If the input LLVM IR module was a compute kernel, how would I go about executing it on an AMD GPU? Can I use the APP SDK to load the binary, perhaps

On May 28, 2012 6:44 AM, "Tom Stellard" <thomas.stellard at amd.com> wrote: > > On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > > Hi Tom, > > > > I have a higher-level question regarding this back-end. If I have an LLVM > > IR module and run it through this back-end, it seems like the only output > > option is a binary

> -----Original Message----- > From: Stellard, Thomas > Sent: Monday, May 28, 2012 9:07 AM > To: Justin Holewinski > Cc: Villmow, Micah; Tom Stellard; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] RFC: R600, a new backend for AMD GPUs > > On Mon, May 28, 2012 at 08:54:41AM -0700, Justin Holewinski wrote: > > On May 28, 2012 6:44 AM, "Tom Stellard"

On Mon, Mar 26, 2012 at 12:50:07PM -0400, Tom Stellard wrote: > Hi, > > We've been working on an LLVM backend for the previous generation of AMD > GPUs (HD 2XXX - HD 6XXX) and we would like submit it for inclusion in the > main LLVM tree. The latest code can be found in this git repository: > http://cgit.freedesktop.org/~tstellar/llvm/ in the r600-initial-review > branch

On Mon, Apr 09, 2012 at 09:37:37AM -0400, Tom Stellard wrote: > On Mon, Mar 26, 2012 at 12:50:07PM -0400, Tom Stellard wrote: > > Hi, > > > > We've been working on an LLVM backend for the previous generation of AMD > > GPUs (HD 2XXX - HD 6XXX) and we would like submit it for inclusion in the > > main LLVM tree. The latest code can be found in this git

On Mon, Mar 26, 2012 at 12:50:07PM -0400, Tom Stellard wrote: > Hi, > > We've been working on an LLVM backend for the previous generation of AMD > GPUs (HD 2XXX - HD 6XXX) and we would like submit it for inclusion in the > main LLVM tree. The latest code can be found in this git repository: > http://cgit.freedesktop.org/~tstellar/llvm/ in the r600-initial-review > branch

Tom, Two things. One is missing tests. I have some I could send you, but they are mainly OpenCL based for the AMDIL backend, not for the R600. That brings me to the second thing. Are the AMDIL backend and the R600 backend the same, or not? At this point, they really do feel like they are separate back ends, with one dependent on the other. As there is no other backend that is dependent on

On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > Hi Tom, > > I have a higher-level question regarding this back-end. If I have an LLVM > IR module and run it through this back-end, it seems like the only output > option is a binary format. Is this a device binary, or another > intermediate format? > > If the input LLVM IR module was a compute kernel,

On Mon, May 28, 2012 at 08:54:41AM -0700, Justin Holewinski wrote: > On May 28, 2012 6:44 AM, "Tom Stellard" <thomas.stellard at amd.com> wrote: > > > > On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > > > Hi Tom, > > > > > > I have a higher-level question regarding this back-end. If I have an > LLVM > > >

Is there a version of the AMDIL back-end that is compatible with LLVM 3.0/3.1? On Tue, May 29, 2012 at 8:33 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > > > > -----Original Message----- > > From: Stellard, Thomas > > Sent: Monday, May 28, 2012 9:07 AM > > To: Justin Holewinski > > Cc: Villmow, Micah; Tom Stellard; llvmdev at cs.uiuc.edu >

On Mon, Mar 26, 2012 at 01:22:01PM -0400, Villmow, Micah wrote: > Tom, > Two things. One is missing tests. I have some I could send you, but they are mainly OpenCL based for the AMDIL backend, not for the R600. > I've started working on the tests, and I've pushed a few up to my llvm repo. I can add the AMDIL tests too if you want to send them. I think they will be helpful.

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd

Moving this thread to llvmdev. On Tue, Oct 30, 2012 at 11:09:34PM -0700, Chris Lattner wrote: > On Oct 30, 2012, at 11:35 AM, Tom Stellard <tom at stellard.net> wrote: > >> Hi Tom, > >> > >> Time is running short, but this would be great. The best place to start is to begin decomposing the mega-patch into individual pieces that makes sense. Do you have

On 01.11.2012, at 14:44, Tom Stellard <tom at stellard.net> wrote: > Moving this thread to llvmdev. > > On Tue, Oct 30, 2012 at 11:09:34PM -0700, Chris Lattner wrote: >> On Oct 30, 2012, at 11:35 AM, Tom Stellard <tom at stellard.net> wrote: >>>> Hi Tom, >>>> >>>> Time is running short, but this would be great. The best place to

On Sat, Nov 17, 2012 at 10:56:26PM +0100, Benjamin Kramer wrote: > > On 01.11.2012, at 14:44, Tom Stellard <tom at stellard.net> wrote: > > > Moving this thread to llvmdev. > > > > On Tue, Oct 30, 2012 at 11:09:34PM -0700, Chris Lattner wrote: > >> On Oct 30, 2012, at 11:35 AM, Tom Stellard <tom at stellard.net> wrote: > >>>> Hi

> On Feb 11, 2015, at 11:37 AM, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Feb 11, 2015 at 04:06:10PM +0000, Sam Kellett wrote: >> Would it be feasible to compile LLVM IR into shading language assembler? If >> so, is this already being done? >> > > The R600 backend does this in conjunction with the Open Source mesa3D > project:

Would it be feasible to compile LLVM IR into shading language assembler? If so, is this already being done? This would provide the obvious benefits of not having to differentiate between GLSL and HLSL (et al.) and the pleasure of using some other language to write and test the shader's that have support as an LLVM frontend. I've googled and found nothing about this. The only LLVM and

So, basically, you allocate the rasterizer units according to the vertex shader, and when the fragment shader comes up, you say "write rasterizer output 4 to fragment input 1000000"? The current nouveau drivers can't do this. There are "routing" registers in hardware, but I think the nVidia proprietary driver (at least without GLSL) leaves them unaltered after

On Fri, Oct 19, 2012 at 04:38:29PM +0100, Marcello Maggioni wrote: > Hello, > I'm working on a compiler based on LLVM for a SIMD architecture that > supports instruction predication. We would like to implement > branching on this architecture using predication. > As you know the LLVM-IR doesn't support instruction predication, so > I'm not exactly sure on what is the

Hello. Sorry I am not sure this question should go to llvm or mesa3d-dev mailing list, so I post it to both. I am writing a llvm backend for a modern graphics processor which has a ISA very similar to that of Direct 3D. I am reading the code in Gallium-3D driver in a mesa3d branch, which converts the shader programs (TGSI tokens) to LLVM IR. For the shader instruction also found in LLVM IR,