Open Intermediate Language

I published my suggestions in my blog … tions.html

From application developer position I suggest:

  • extend synchronization functionality, transactional memory is not worst idea to try!
  • dynamic memory allocation, malloc/free is not right solution (slow), specially designed GC is better.
  • extend input/output capabilities, i want printf in kernel function :)!

From system developer position I suggest:

  • OpenCL Intermediate Language.

I like the idea of an Open Intermediate Language, then maybe there would be support for some inline assembly when computationally advantageous. Right now it requires a big round about to try to insert custom IL code.

An intermediate language won’t solve anything: it does not really protect the IP and it does neither optimize the loading/executing speed ( the IL program needs to be again recompiled and optimized ).

I really prefer a per-IHV specific offline compilation tool like Intel’s IOC. That would be much more optimized and fast to load.

If I were Khornos I would force all the implementors to make that offline precompilation tool so the programers can pre-compile and optimize their programs for their specific platforms.

Intel IOC ftw.

First of all OpenIL is important for new hardware research & development, current proprietary ILs, like AMD-IL, NV-PTX are unusable, too fat.

Industry future will be more open, that’s why standards like OpenCL is so important!

Being involved in reconfigurable computing R&D I’m developing OpenIL, very lightweight minimalistic design, just few instruction classes, see following examples:

  1. conditionals, example JIF r0,r1; jump to r1 addr if r0 is true;
  2. data transfers, example LD r0,g.r1; load r0 from global memory;
  3. nd-range, example ndr.lid r0; load r0 local thread id;
  4. sync, example barrier; sync all threads in a group;
  5. alu, example add r0,r1,r2; r0=r1+r2;
    and some target architecture extensions classes;

Such OpenIL is based on a minimalistic reconfigurable instruction set, oriented to used in scalable, mass parallel systems on chip with thousands lightweight cores.

Sometimes it’s not so easy to explain this concept to customers, that instruction set is adoptable, optimized in a compilation time, when you compile your kernel function :slight_smile:

OpenIL is not just specification & header files but also compilation back-end rules.

The same situation with hardware, to run OpenIL instructions we need minimalistic lightweight reconfigurable IPs library to synthesize executable cores, generated at compilation time :slight_smile:

Such flexibility is achievable on reconfigurable devices, like FPGAs.

So, where is openness & where is a competition? OpenIL as a possible standard can help to move industry forward faster. Synthesis tools, IPs may be both proprietary & open.

Future OpenIL notes this forum & here

“better”? No! Far from it!

Garbage collection is a massive problem for some classes of application. Anything that’s aggressively interactive (like a game or an interactive simulation) will suffer badly from the uneven execution rates you get when the cost of freeing up dynamic memory happen in a ‘lump’. malloc & free might be a little slower (although - I might want to debate that too) - but they have the massive advantage that they amortize the cost over time and leave control of when the time is consumed in the hands of the application.

Video games typically have loop cycle times around 16ms - if garbage collection for a half million line of code application takes more than (let’s say) a half millisecond - then that is likely to be unacceptable.

Once of the things the IHV learned is that DX-IL is not good. That’s why they decided by consensum not to use a IL for OpenGL by very good reasons.

In case you want to optimise the loading time of a kernel or to protect the IP, it’s much better to develop an offline compilation tool like CUDA’s nvcc or Intel OpenCL SDK’s Offline Compilation Tool.

Once of the things the IHV learned is that DX-IL is not good. That’s why they decided by consensum not to use a IL for OpenGL by very good reasons.

There are several reasons why OpenGL doesn’t have an intermediate language and it’s not because “DX-IL is not good”.

Sorry about being pedantic but I really dislike misinformation.

Can you use LLVM for this?

My understanding is that AMD’s OpenCL compiler outputs to LLVM.
The LLVM is then optimised and translated to AMD IL for further optimisation.

There is no reason a LLVM to Nivida PTX back end couldn’t be implemented.

What’s needed is a standardisation the LLVM for GPU. (metadata etc)

If no Open Intermediate Language is available, then how about some extra supported functions in OpenCL for integer carry add (carry in and out), borrow sub (borrow in and out), etc.

In the meantime, are there any efficient methods to performing such operations without many conditional tests or arithmetic operations?

Also, since there is no operator overloading in OpenCL, developing basic data types (say 256 bit integers or floating-point numbers) is extremely tedious, much more than it should be. Since 128 bit integers (long long) and floating-point numbers (cl_quad) are reserved, how does Khronos plan to implement them?

Sean, if you want your post about integer carry to be visible you should put it in its own thread.

Added an illustration & description of OpenIL concept in my blog

OpenIL vs OpenCL - not correct but, OpenCL is not just a language it’s an architecture too.

OpenIL more simple & flexible, researchers can play with different architecture experiments right on FPGA or prototype cores.

OpenIL is not just instruction set (IS), but IS + metadata.

I think you should make it a standard! Problem solver.

see slide 13 … 4.2011.pdf