llvm dev - Jul 2010 - [LLVMdev] Questions about GPU code generation/ VS development

Hey everyone,

I've been working for a while on a virtual machine/DSL (for lack of a more
precise term) specialised for graphics. I hope to allow domain specific
optimizations, eg folding together post-processing passes, or automatic
LODing for procedural textures. I'm planning to make the renderer itself to
be defined at runtime, to allow foward rendering, deferred rendering,
raytracing, or a combination of all 3. Of course, this is lot to chew on, so
for now it's more of a proof of concept than anything production-ready.

Due to my unfamiliarity with LLVM, I do have some broad questions though. If
somebody can answer, or just point me to the relevant documentation/code, I
would be very grateful.

Right now I use my own code to schedule between the GPU code (OpenCL and
GLSL), and to generate the GPU code. In fact, I only use LLVM to generate
the CPU side code.

1. Which steps would it take to implement an OpenCL/GLSL backend to LLVM?
What is the level of vector integration in the core? Is there already some
work done in this direction I could look at/reuse?
2. Would it make sense to use LLVM to drive the whole compilation process,
considering I will operate on high level concepts, eg convolutions,
frequency analysis, error metrics? Or should I do break down these things
first and then use LLVM for the lower level code?
3. ATM I'm using VS2008 as my environment, and LLVM from head. Timewise, am
I shooting myself in the foot? I'm hesitant to switch to another platform,
as I have a lot of experience with VS, but I'm unsure how well the LLVM
support stacks up to Mac/Linux support.
4. I'm using my own custom 3d engine, which should have it's routines
called
dynamically. Does this mean I have to run CLang on it to make it callable
from LLVM generated code, or should I just be able to call it as as external
code?

I apologize in advance if some of these questions are basic or too broad, I
recently hit a bit of a brick wall designing the guts of the system, and
would love to benefit from the opinion of experienced LLVM users. Thank you
for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100723/0449b490/attachment.html>

On 23/07/2010, at 7:25 PM, Daan Nijs wrote:
> Hey everyone,
> 
> I've been working for a while on a virtual machine/DSL (for lack of a
more precise term) specialised for graphics. I hope to allow domain specific
optimizations, eg folding together post-processing passes, or automatic LODing
for procedural textures. I'm planning to make the renderer itself to be
defined at runtime, to allow foward rendering, deferred rendering, raytracing,
or a combination of all 3. Of course, this is lot to chew on, so for now
it's more of a proof of concept than anything production-ready.
> 
> Due to my unfamiliarity with LLVM, I do have some broad questions though.
If somebody can answer, or just point me to the relevant documentation/code, I
would be very grateful.
> 
> Right now I use my own code to schedule between the GPU code (OpenCL and
GLSL), and to generate the GPU code. In fact, I only use LLVM to generate the
CPU side code.
> 
> 1. Which steps would it take to implement an OpenCL/GLSL backend to LLVM?
What is the level of vector integration in the core? Is there already some work
done in this direction I could look at/reuse?
> 2. Would it make sense to use LLVM to drive the whole compilation process,
considering I will operate on high level concepts, eg convolutions, frequency
analysis, error metrics? Or should I do break down these things first and then
use LLVM for the lower level code?
> 3. ATM I'm using VS2008 as my environment, and LLVM from head.
Timewise, am I shooting myself in the foot? I'm hesitant to switch to
another platform, as I have a lot of experience with VS, but I'm unsure how
well the LLVM support stacks up to Mac/Linux support.
I'm on linux for development, but all of my colleagues are on VS2005. We
have been on LLVM 2.7 ever since it's release as we need a stable platform
because we are not only working on our own ongoing internal R&D in the
longer term but also have products shipping to customers from the short term
onward. Apart from lots of innocent, but annoying, warnings coming out on
windows, we have seen no execution errors from LLVM apart from a few bugs which
are not windows specific but rather cross-platform (and all of which are fixed
on LLVM trunk). In these cases we have our own internal patches applied until
LLVM 2.8 is released. If you have no other good reason to want to move from
windows to linux then I would say that our experience demonstrates that LLVM in
itself provides no justification either way, so choose on your own other merits
in terms of other things whether you are happy on windows or not. Or in fact
choose based on what your customer expects.
> 4. I'm using my own custom 3d engine, which should have it's
routines called dynamically. Does this mean I have to run CLang on it to make it
callable from LLVM generated code, or should I just be able to call it as as
external code?
> 
> I apologize in advance if some of these questions are basic or too broad, I
recently hit a bit of a brick wall designing the guts of the system, and would
love to benefit from the opinion of experienced LLVM users. Thank you for your
time.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Dan,
 I've been working on an OpenCL GPU language code generator for the last two
years, so I can answer some of your questions.
1) I would check out the gallium 3d project as they are doing something very
similar to this already, but are mainly targeting GLSL and not OpenCL. Support
for vectors is very good in LLVM, as long as your vectors are power of 2 in
size. Occasionally I run into a problem where vector support is non-existent,
but adding it from similar code isn't too much of an issue.
2) LLVM is low level, you might want to look into HLVM for your high level
optimizations.
3) I've developed on Mac, Linux and Windows and have not had trouble with
LLVM from that perspective.  So there isn't really a problem to worry about
here.

Some other things to take into account that are problematic for LLVM that
I've ran across. For example, LLVM does not produce 'good' flow
control code for vector architecture with the default passes enabled. The passes
need to be tweaked to disable many flow control optimizations. Another issue is
the fact that the GPU language I am targeting has constant resource ID's and
a non-uniform address space. So keeping track of which pointer belongs to which
resource ID is very difficult and in some cases impossible at the machine
instruction level.

We use a separate compiler for ISA generation/scheduling/register allocation and
not LLVM, so I can't comment to deeply on how LLVM works here, but I believe
it would be difficult to fix llvm to generate ISA for our GPU architecture as
the concepts that the architecture has does not exist in llvm.

Hope this helps,
Micah

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Daan Nijs
Sent: Friday, July 23, 2010 2:55 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Questions about GPU code generation/ VS development

Hey everyone,

I've been working for a while on a virtual machine/DSL (for lack of a more
precise term) specialised for graphics. I hope to allow domain specific
optimizations, eg folding together post-processing passes, or automatic LODing
for procedural textures. I'm planning to make the renderer itself to be
defined at runtime, to allow foward rendering, deferred rendering, raytracing,
or a combination of all 3. Of course, this is lot to chew on, so for now
it's more of a proof of concept than anything production-ready.

Due to my unfamiliarity with LLVM, I do have some broad questions though. If
somebody can answer, or just point me to the relevant documentation/code, I
would be very grateful.

Right now I use my own code to schedule between the GPU code (OpenCL and GLSL),
and to generate the GPU code. In fact, I only use LLVM to generate the CPU side
code.

1. Which steps would it take to implement an OpenCL/GLSL backend to LLVM? What
is the level of vector integration in the core? Is there already some work done
in this direction I could look at/reuse?
2. Would it make sense to use LLVM to drive the whole compilation process,
considering I will operate on high level concepts, eg convolutions, frequency
analysis, error metrics? Or should I do break down these things first and then
use LLVM for the lower level code?
3. ATM I'm using VS2008 as my environment, and LLVM from head. Timewise, am
I shooting myself in the foot? I'm hesitant to switch to another platform,
as I have a lot of experience with VS, but I'm unsure how well the LLVM
support stacks up to Mac/Linux support.
4. I'm using my own custom 3d engine, which should have it's routines
called dynamically. Does this mean I have to run CLang on it to make it callable
from LLVM generated code, or should I just be able to call it as as external
code?

I apologize in advance if some of these questions are basic or too broad, I
recently hit a bit of a brick wall designing the guts of the system, and would
love to benefit from the opinion of experienced LLVM users. Thank you for your
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100723/63ccf994/attachment.html>

Daan Nijs wrote:
> 4. I'm using my own custom 3d engine, which should have it's
routines
> called dynamically. Does this mean I have to run CLang on it to make it
> callable from LLVM generated code, or should I just be able to call it
> as as external code?
I recently had the opportunity to explain my opinion on this. Here's the 
mailing list archive links:

   http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033139.html
[ the thread got broken but continues here: ]
   http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033149.html

Nick