Re: Is GPU computing dead already?

(L) [2013/04/05] [Geri] [Re: Is GPU computing dead already?] Wayback!

i think that gpgpu conception is useless. i would program a smp monolithic neumann architecture (cpu with lot of true cores) than any assymethric thing. so, for me, N*random core is the winner.
the industry also think this, there is only a few hundred app that can properly utilise gpgpu
and there is 10 million software that runs on REAL cpu-s
this competition is alreday win by cpu.
-you cant write true software for a gpu:
-you cant write TRUE algorythm
-you have no access to the gpu hardware at all, you dont know what happens inside opencl/cuda/or in your shader
-you cant access the real memory
-they calim its 10x fater than cpu - with real algorythms, but sometimes even a 16 mhz 386 is around ~2x faster than a 2000 usd graphics accelerator
-you cant just interact with the os
-no true c++ compiler for the gpgpu
-you need a driver interface to access it, loosing thousands of clock cycles, so you cant use it as a coprocessor
-you cant even write secure code, becouse gpgpu needs to compile the code on-the-fly. no serious software will born on this conception at all
-gpgpu conception is its on the market since 5 years ago. no serious software even made with it. even the flashplayer's only reaction from turning on the gpgpu acceleration is to throw a bsod on some configs
-strong gpu is even more rare than a strong multicore cpu in the computers in these days
-the gpgpu eats a lot of extra power, it makes a lot of extra heat
-you cant call a fopen, you cant boot windows on the gpu... becouse if you will be able to do this once, it will not a gpu any more - it will become a cpu.
-nobody want to program on this crap, amd and intel, please give us more cpu cores thx.
-too low popularity, too many bugs
-therefore, the conception of the gpgpu is wrong in my oppinion; gpgpu makes no sense.

(L) [2013/04/18] [spectral] [Re: Is GPU computing dead already?] Wayback!

>> Dade wrote:dbz wrote:OpenCL not advancing beyond basic C
It such huge pain for me: maintaining 2 different code bases for CPU and GPU rendering is such a huge problem.
However, it is an interesting trend: OpenCL C is used portable "assembler" across GPUs/CPUs and there are front-ends to translate the code from C++ ([LINK http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048012.html], [LINK https://bitbucket.org/gnarf/axtor/overview]), C++ AMP (from Intel), etc. to OpenCL C.
What it is ? an OpenCL decompiler ? For which purpose it is for ?
BTW, I have look for the "front ends" to convert C++ to OpenCL, but found nothing ?

(L) [2013/04/19] [hobold] [Re: Is GPU computing dead already?] Wayback!

>> keldor314 wrote:This means that in theory, you can take any language that supports LLVM and compile it directly to a GPU binary.
The problem is that the GPU target instruction sets have limitations. The LLVM internal representation may contain constructs that cannot directly be mapped to a GPU target ... the respective backend would simply output an error and give up.
The point of the quoted whitepaper is in the code transformations that can be applied to LLVM intermediate representation, such that the transformed code becomes digestible even with the limitations of a typical GPU. These code transformations may have a performance cost (as visible in at least one of the test cases of the paper). And the set of transformations presented may or may not be complete; the paper does not really attempt to find a solid theoretical foundation (this is a bachelor's thesis after all, but an exceptionally bold and insightful one).

(L) [2013/04/19] [graphicsMan] [Re: Is GPU computing dead already?] Wayback!

Sounds interesting.  I'll have to look at it.
The fact remains that CPUs cannot scale the way they did in the past.  There are also limitations to how well they will scale out in their current trend (adding cores).  You'll run up against die size limits rather quickly if you simply try to double or quadruple the number of cores on a single processor.
That's why for Xeon Phi they had to use such scaled back cores; no fancy branch prediction, no huge instruction pipeline, and they traded it for simple mechanisms to enable higher compute.  Instead of super smart processors, they opted for dumber ones that have 4 threads per core to help hide latencies (is this enough?), and instead of adding more cores, they opted for wide SIMD on each core.
Of course, unless you have a very simple program to optimize, you'll need to go low-level to take advantage of the parallely goodness, which is a pain in the ass.  Compilers are constantly getting better, but it's simply asking too much to take a regular-ol C++ program and have it run near-optimally on a Phi or a GPU.  The best you can hope for is easy parallelism over some kinds of loops (pragma approach), which for complex programs is simply not going to cut it.
OpenCL and CUDA force the programmer to think differently in order to get the parallelism.  CUDA gives you the latest and greatest features of the NVIDIA GPUs, and allows C++ kernels, but still has severe limitations for the programmer, and only runs on NV (for all real intents and purposes).  OpenCL will give you good performance if your program does not require thread cross-talk, but otherwise will likely suck.  Phi has a couple of SPMD programming options that seem pretty nice, but do not allow C++ code, and you still have to be careful when and how you invoke that code... If your program is running on a normal Xeon, and you fire calls through to the Phi, you still incur high latency, so you had better batch a lot of work.
All this is to say that (a) new SIMD/SIMT architectures are needed in order to scale because old-style CPUs will scale at a much slower pace going forward, and (b) because (a) is inevitable, we had better continue to improve our programming paradigms, because, while programming these architectures may suck enough now to avoid using GPUs/Phi/similar, eventually if you care about performance and parallelism, you're going to have to move this direction.

(L) [2018/11/14] [ost by ziu] [Re: Is GPU computing dead already?] Wayback!

Not a lot I think. OpenCL was killed in Android and most browsers disable WebCL because they consider it a security hazard for example.

On the positive side:
- NVIDIA now supports a more recent version of OpenCL.
- Adobe supports and uses OpenCL in its products.
- A lot of tools code was open sourced so the barrier to make an OpenCL ICD is now a lot lower. All the GPU hardware backends have basically been merged into LLVM. Intel made available the code for an OpenCL 2.x frontend for LLVM. Khronos put out SPIR-V code for LLVM. AFAIK however this still needs to be all integrated properly. Does anyone still care at this point?
- There are now multi-platform implementations like 'pocl'. But I still think that it is a tad bit on the unstable side and now suitable for production uses yet. At least last time I tested it was like that on my test applications.

- CUDA has found use in AI machine learning applications.
- CUDA keeps evolving but, at least to me, it seems most advances are either tiny increments, or long promised features which still do not work as you would expect them to do. Again and again.
- Google made their own CUDA implementation.

I personally have no issues with only having C support. I think the C++ features are a luxury really. I think SIMT is a really great programming model. It is much simpler to program for, in my opinion, than mixing and matching multi-threaded code with vector code in umpteen hardware dependent implementations.

I think OpenCL C does for multi-cores and SIMD what C did for single-cores. You finally have a portable code base which can compile in multiple platforms and run. You might need hardware specific performance tweaks for optimum performance. But those are minimal. The main issue is that you still cannot access the ROP units in GPUs in OpenCL and that OpenCL/OpenGL integration is still quite crappy. OpenCL was also, I think, thrown off track by Vulkan. Some people seem to think it is a replacement for it, when it isn't, it's basically a replacement for OpenGL and shaders. OpenCL-Next is still nowhere to be seen. Because of that a lot of people have dragged their feet with OpenCL adoption even more.

Debugging on either language platform is still a crapshoot because of the tools, lack of hardware support for proper debugging, memory protection is another crapshoot. I want a debugger which shows me the state of all the threads/fibers in an easy to understand fashion and allows me to single-step through code. I want a profiler which easily allows me to check memory use patterns. Heck even if it was only software emulated it would be better than nothing. Oh the debugger shouldn't crash willy nilly. I know these things are hard though.

With the slowing down of Moore's law one would expect people to give more attention to solutions like SIMT. I expect the hardware to get more parallel and further and further apart from the usual single threaded programming model we know and love in the future. As chip fab process technology loses dominance, it has to be compensated with architectural improvements. This might only be a problem for like a decade until someone comes up with something better than today's silicon. But I think we are going to see at least a decade gap happen which will be filled with novel hardware platform designs. In fact we are already seeing it happen now with both GPUs and AI co-processing units becoming de facto staples.

Re: Is GPU computing dead already? back

Board: Home Board index Raytracing General Development