Running OpenCL On The GPU With Gallium3D
Phoronix: Running OpenCL On The GPU With Gallium3D
With all of the recent improvements going into Mesa/Gallium3D, along with some work advancements to the AMD GPU LLVM back-end, it's slowly becoming a suitable time for enthusiasts wishing to experiment with OpenCL on the open-source Linux graphics stack through Gallium3D and the "Clover" state tracker...
Does any software applications on Linux support GPGPU or OpenCL?
Does GIMP or Blender support GPGPU or OpenCL?
Blender does support GPU rendering with their Cycles Render Engine. There is work on openCL in gegl (the library that new versions gimp uses for graphics operations), but i am not sure what state it is in. Darktable also has openCL.
Gegl supports OpenCL. r600g and clover is very close to being able to handle the Gegl image operations. A few months ago, with some small patches to Gegl to work around missing libclc standard library implementations, I had some of the Gegl operations working with clover and r600g.
Originally Posted by ssam
Thomas Stellard, i am involved in project that maybe ambitious and biggest OpenCL kernel ever exist, 3D raytracer Blender Cycles, and have very bad experience with proprietary AMD OpenCL realisation. For now, AMD compiler just eat enormous RAM (32+GB) and still puke on correct code. We have contacts with AMD driver team, and last owrds they aware and give up, suggesting to cut kernel size. My current work will add even more code to it to get more features, making code 2x large or more. Any chance you can get Clover to stage when it will "eat" such huge kernels w/o issues, as NVidia do? Unfortunately, it use 2D images and other builtings and i cannot try to run it as this stage, even when cut code to minimal. My expectations that GCN have full general CPU stack/call support, and can easily avoid old "flatten" architecture, that really can not unroll complex code graph to internal VLIW form. Is it correct? Just in case, for now must say that Clover is only real hope to run Blender Cycles on AMD hardware.
Originally Posted by tstellar
An open source CPU driver for OpenCL would be a good thing to have first.
Don't see why the author seems more enthousiastic about GPU drivers than the LLVM CPU driver.
Most people with x86 based CPU's would be able to run it.
Can make it run on Linux.
Can develop it in conjunction with tests and then the tests with other drivers.
App developers can easier get their hands on an OpenCL driver this way.
It's a chicken and egg problem.
Originally Posted by uid313
Without a proper and widely deployed OpenCL implementation, there won't be too many people willing to use OpenCL.
Last edited by zxy_thf; 01-23-2013 at 06:53 AM.
Reason: typo fix
Not really, because that is strictly restricted to the blobs. You might find yourself a few corner-case users, but certainly not widespread deployment. Why would anyone build software depending on openCL if they can't trust that their customers will be able to use it?
Originally Posted by pingufunkybeat
In other words, it MUST be supported by both AMD and Intel **open source** drivers, AND have a solid CPU fallback, before software developers can trust in its availability.
I don't think that consumer any software will DEPEND on OpenCL any time soon. But it is reasonable to provide an OpenCL-accelerated path for some computationally intensive operations if there are enough people who can make use of it. And there are enough blob users out there.
Originally Posted by droidhacker
I'm just saying that "nobody can run OpenCL" is not a good argument. Plenty of people can already, others will follow as open drivers mature.