6 ms·

The entire GPU programming landscape is so fragmented and unapproachable now. If they'd only exposed the processors directly and worked to unify behind a common

by zurn 12y ago

The entire GPU programming landscape is so fragmented and unapproachable now. If they'd only exposed the processors directly and worked to unify behind a common compiler frontend... Imagine a world where a good GPGPU language was a standard GCC/LLVM frontend and all the GPU vendors worked in harmony to improve their back-ends in the upstream compiler. This would enable development of new cross-vendor GPU languages to compete with the ailing OpenCL. (This is what Apple has done with Metal Shading Language btw, minus the open source part. And what Intel's Larrabee would have enabled.) Even if you disregard the licensing, the union of NV + AMD + Intel capabilities (software stacks included) is so weak that it almost never worth the effort. The comically bad software from AMD and lack of hardware oomph from Intel means the only option is to require NVidia and build on their software support. This is passable for a narrow sector of activities that can tolerate vendor lock-in (Cuda), like short lived HPC projects. All this has resulted in lack of open GPU programming languages. OpenCL is better than nothing, but even if the implementations were of usable quality, it's not a good compiler target for higher level languages and it's not a good language to write by hand. The situation pretty much guarantees GPU computing stays in the fringes for the foreseeable future.

graphene 12y ago
AMD and ARM are working on something that sounds like what you describe: http://en.wikipedia.org/wiki/Heterogeneous_System_Architecture http://en.wikipedia.org/wiki/Heterogeneous_System_Architectu... I believe nVidia has a similar effort going (can't remember the name), so it's still not a single agreed standard, but it's moving in that direction I feel.
- lightcatcher 12y ago
  nVidia's PTX is the most similar thing I can think of (and I know nVidia's GPGPU products pretty well right now). PTX is an ISA for a virtual machine, which makes it similar to HSAIL. PTX doesn't come with a memory model specification though. However, I don't think either HSA or PTX is very important if nVidia, AMD, and Intel (wrt Xeon Phi's) don't start agreeing on standards. I haven't seen anything to convince me that nVidia wants to work within standards, and CUDA seems to have most of the market share right now, so I'm not too hopefully for portable heterogeneous computing in the near future. To my grandparent poster: I don't think working with GPUs is that bad right now if you bind yourself to a vendor. In my experience, drinking the CUDA kool-aid (CU-aid?) isn't all that bad.
pandaman 12y ago
I think it's too early to expose processors. The GPU processors are still beyond a thick layer of fixed-function hardware. The good thing is that everybody is working to get rid of it and you can see how more and more HW is replaced with software. For example, the memory access used to be entirely in the fixed function hardware and the processor could only index buffers that were set up elsewhere. Nowadays it's pretty common to have full access to memory from the processor itself. In a few years we will get GPUs that will be able to run compute tasks entirely in software (the graphics will most likely remain fixed-function for much longer) and then exposing the GPU ISA will make much more sense.
foxhill 12y ago
> The entire GPU programming landscape is so fragmented and unapproachable now. it's fragmented, true, but it's not that bad. > If they'd only exposed the processors directly and worked to unify behind a common compiler frontend... they don't need to, LLVM-SPIR is supposed to enable this - compile kernels to IR and let the runtime JIT it into the GPUs required binary. > And what Intel's Larrabee would have enabled. intel did release the larrabee, sort of. it's called the Xeon Phi (and it isn't exactly great..) > The comically bad software from AMD AMD have a well deserved reputation, but things aren't that bad now. > OpenCL is better than nothing, but even if the implementations were of usable quality i don't know what problems you run into specifically, but most of the runtimes are definitely of usable quality. ironically, it's apple have the worst runtime (but even that isn't so bad).. think of that what you will! things have improved in the OpenCL space, and they will continue to improve for the foreseeable future. AMD and intel are doing good here, and nvidia actually do support OpenCL. questions of performance portability aside, CL is a pretty good option for people wanting to run on GPUs.
- zurn 12y ago
  LLVM-SPIR doesn't have any production quality implementations for the popular hardware, nor are any announced. This nonwithstanding, it's only proof of the fragmentation as it's merely one of many vapourware competitors on this sector. Xeon Phi is not Larrabee the GPU, it's a product of salvage & pivot from the project resulting in a HPC sidecar. (HPC sector I adressed in my original comment).

by zurn 12y ago

graphene 12y ago

AMD and ARM are working on something that sounds like what you describe: http://en.wikipedia.org/wiki/Heterogeneous_System_Architecture http://en.wikipedia.org/wiki/Heterogeneous_System_Architectu... I believe nVidia has a similar effort going (can't remember the name), so it's still not a single agreed standard, but it's moving in that direction I feel.

lightcatcher 12y ago
nVidia's PTX is the most similar thing I can think of (and I know nVidia's GPGPU products pretty well right now). PTX is an ISA for a virtual machine, which makes it similar to HSAIL. PTX doesn't come with a memory model specification though. However, I don't think either HSA or PTX is very important if nVidia, AMD, and Intel (wrt Xeon Phi's) don't start agreeing on standards. I haven't seen anything to convince me that nVidia wants to work within standards, and CUDA seems to have most of the market share right now, so I'm not too hopefully for portable heterogeneous computing in the near future. To my grandparent poster: I don't think working with GPUs is that bad right now if you bind yourself to a vendor. In my experience, drinking the CUDA kool-aid (CU-aid?) isn't all that bad.

pandaman 12y ago

I think it's too early to expose processors. The GPU processors are still beyond a thick layer of fixed-function hardware. The good thing is that everybody is working to get rid of it and you can see how more and more HW is replaced with software. For example, the memory access used to be entirely in the fixed function hardware and the processor could only index buffers that were set up elsewhere. Nowadays it's pretty common to have full access to memory from the processor itself. In a few years we will get GPUs that will be able to run compute tasks entirely in software (the graphics will most likely remain fixed-function for much longer) and then exposing the GPU ISA will make much more sense.

foxhill 12y ago

> The entire GPU programming landscape is so fragmented and unapproachable now. it's fragmented, true, but it's not that bad. > If they'd only exposed the processors directly and worked to unify behind a common compiler frontend... they don't need to, LLVM-SPIR is supposed to enable this - compile kernels to IR and let the runtime JIT it into the GPUs required binary. > And what Intel's Larrabee would have enabled. intel did release the larrabee, sort of. it's called the Xeon Phi (and it isn't exactly great..) > The comically bad software from AMD AMD have a well deserved reputation, but things aren't that bad now. > OpenCL is better than nothing, but even if the implementations were of usable quality i don't know what problems you run into specifically, but most of the runtimes are definitely of usable quality. ironically, it's apple have the worst runtime (but even that isn't so bad).. think of that what you will! things have improved in the OpenCL space, and they will continue to improve for the foreseeable future. AMD and intel are doing good here, and nvidia actually do support OpenCL. questions of performance portability aside, CL is a pretty good option for people wanting to run on GPUs.

zurn 12y ago
LLVM-SPIR doesn't have any production quality implementations for the popular hardware, nor are any announced. This nonwithstanding, it's only proof of the fragmentation as it's merely one of many vapourware competitors on this sector. Xeon Phi is not Larrabee the GPU, it's a product of salvage & pivot from the project resulting in a HPC sidecar. (HPC sector I adressed in my original comment).