Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 3:32 am, Bill Gribble wrote: > On Tue, 2012-12-11 at 02:56 +1100, Patrick Shirkey wrote: >> On Mon, December 10, 2012 10:42 pm, Bill Gribble wrote: >> We have several headless machines running GPU's with thousands of >> processing units available. Much more power than the first "Lord of the >> Rings" movie was made with. > > Good stuff to have available! Even on a normal laptop with external GPU > chipset and the builtin Intel one too there's a pretty powerful idle > processor. That's why I started getting interested. Also, I penciled > out a hardware setup that would allow a laptop to add external PCI > graphics cards for this purpose, seems like a great choice for > convolution reverbs, long FIR filters for linear-phase EQ, etc. > It's also handy for rendering video graphics and ffmpeg/libavcodec has some support for accelerated processing too. Blender and Ardour make an incredibly powerful combination but the complete toolset is just incredible with a tightly honed cluster. > I mention interactions because there are a few commercial > GPU-accelerated audio plugins for Windows (convolution reverb was all I > could find, can't remember the name offhand), and I spent some time > scraping forums at the manufacturer, gearslutz, etc for information > about real-world performance. The reports were that the latency for > executing OpenCL kernels was pretty unpredictable, and seemed to be > related to resource allocation by the desktop OS. Not an issue in your > case, nor in any case where you have a dedicated chip (or render farm) > for your own purposes. > We are attempting to push the limits of the software and hardware as much as possible. One of my priorities is workflow integration. Figuring out where the holes in the system are and looking at ways to seal them to increase usability. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 7:28 am, David Robillard wrote: > On Tue, 2012-12-11 at 05:40 +1100, Patrick Shirkey wrote: >> On Tue, December 11, 2012 3:33 am, David Robillard wrote: > [...] >> > Unfortunately they're not programmable on Linux yet, only on Windows. >> >> I have been assured that the brand new NUC platform from Intel is fully >> Linux compatible with opengl/cl support too. What specific issues are >> you >> seeing? > > Last I checked, which was quite recently, they were literally not > programmable on Linux whatsoever. The "issue" is it's completely > unsupported on Linux and does not work at all. > > (OpenCL on the normal CPU cores works, mind you, but is embarrassingly > slow compared normal threaded code, so that's useless) > I was told the following regarding the NUC platform and acceleration (The NUC's don't have a GPU): The Kernel driver supports IVB accelerated 3D. You will need, in addition to the Kernel driver, the Mesa component (which is the open source OpenGL implementation).The latest release of Mesa also has full IVB support and had for sometime now. I have been waiting to get hold of one, as they are only a few hundred dollars, to find out exactly how far they can be pushed. They are now on the market for the xmas season. They look like they will be very useful for low energy footprint, high performance multimedia clusters. Also for networked display installations. Solar powered netjack clusters... >> > A complete joke if they're targeting scientific GPGPU, and useless >> for LAD >> > too. Intel seriously needs to get on this and fix their drivers... >> > >> >> Compared to AMD, Intel are actually making a lot of headway with their >> Linux drivers. At least they actually release the specs these days and >> have a full department for Linux development. AMD are having real >> trouble >> getting their heads around the concept of open source *and* multimedia. >> My >> dealings with Intel so far suggest they are light years ahead in terms >> of >> understanding the potential. Compared to AMD it's almost night and day. > > Unfortunately Intel is light years ahead of AMD in most things these > days. Though, if AMD has CPUs with on-die programmable GPUs in Linux, I > for one would be quite a bit more interested... > The AMD Fusion chips are GPU on die and they have recently released a large chunk of opencl tools. I haven't had time over the past few months to look into exactly how much access is now available. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, 2012-12-11 at 05:40 +1100, Patrick Shirkey wrote: > On Tue, December 11, 2012 3:33 am, David Robillard wrote: [...] > > Unfortunately they're not programmable on Linux yet, only on Windows. > > I have been assured that the brand new NUC platform from Intel is fully > Linux compatible with opengl/cl support too. What specific issues are you > seeing? Last I checked, which was quite recently, they were literally not programmable on Linux whatsoever. The "issue" is it's completely unsupported on Linux and does not work at all. (OpenCL on the normal CPU cores works, mind you, but is embarrassingly slow compared normal threaded code, so that's useless) > > A complete joke if they're targeting scientific GPGPU, and useless for LAD > > too. Intel seriously needs to get on this and fix their drivers... > > > > Compared to AMD, Intel are actually making a lot of headway with their > Linux drivers. At least they actually release the specs these days and > have a full department for Linux development. AMD are having real trouble > getting their heads around the concept of open source *and* multimedia. My > dealings with Intel so far suggest they are light years ahead in terms of > understanding the potential. Compared to AMD it's almost night and day. Unfortunately Intel is light years ahead of AMD in most things these days. Though, if AMD has CPUs with on-die programmable GPUs in Linux, I for one would be quite a bit more interested... -dr signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Mon, Dec 10, 2012 at 1:40 PM, Patrick Shirkey wrote: > > > This is the part we are working on. It requires building the software and > then discussing the issues with the driver developers directly. Takes time > and effort in more ways than one. Plus there are certain forces actively > working against us to put as many barriers in the way as possible. > my understanding is that the latency is not a driver issue. its a basic part of how the GPU is designed. they are designed for high bandwidth, not low latency. the driver can't fix this. maybe there is more to it than that. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 3:33 am, David Robillard wrote: > On Mon, 2012-12-10 at 11:12 -0500, Paul Davis wrote: >> On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey < >> pshir...@boosthardware.com> wrote: >> >> > >> > > >> > >> > We have several headless machines running GPU's with thousands of >> > processing units available. Much more power than the first "Lord of >> the >> > Rings" movie was made with. >> > >> > > Still worth exploring though, and a "cl~" processor for my system is >> > > definitely on the todo list. >> > > >> > >> > We are exploring the possibilities here too. Essentially a library >> that >> > allows sending specific operations across a netjack cluster for >> realtime >> > multimedia processing. >> > >> >> you might want to check the latency before you get too far into plans >> like >> this. i've heard that it is improving, but still not really what one >> would >> expect of a "realtime FX processor". > > Indeed. Crazy throughput, but transferring to and from the GPU kills > you. Worth investigating anyway since many-core is probably going to > stick around and become faster, but I doubt current GPUs can achieve > reasonable real-time audio latency. > This is the part we are working on. It requires building the software and then discussing the issues with the driver developers directly. Takes time and effort in more ways than one. Plus there are certain forces actively working against us to put as many barriers in the way as possible. > I think the programmable GPUs on recent Intel chips (Ivy Bridge) is an > interesting development; though much less powerful and far less cores, > they have full memory bandwidth (the other thing that kills you), and > presumably minimal latency since it's on-die. Adding 8 or so cores may > not be in the same realm as adding hundreds, but for many things the > latency and memory bandwidth dominates anyway so a billion cores on a > GPU would still be slower. Anything memory bound is much slower even on > the best GPUs. I'll happily take 8 extra cores on the CPU... > AMD Fusion chips are CPU/GPU combos so you get the best of both in that regard. The next gen HSA platform promises to be even more powerful but AMD will have to survive long enough for that promise to be delivered. They have made some recent progress with opencl support for Linux so that has been well received. > Unfortunately they're not programmable on Linux yet, only on Windows. I have been assured that the brand new NUC platform from Intel is fully Linux compatible with opengl/cl support too. What specific issues are you seeing? > A complete joke if they're targeting scientific GPGPU, and useless for LAD > too. Intel seriously needs to get on this and fix their drivers... > Compared to AMD, Intel are actually making a lot of headway with their Linux drivers. At least they actually release the specs these days and have a full department for Linux development. AMD are having real trouble getting their heads around the concept of open source *and* multimedia. My dealings with Intel so far suggest they are light years ahead in terms of understanding the potential. Compared to AMD it's almost night and day. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Mon, 2012-12-10 at 11:12 -0500, Paul Davis wrote: > On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey < > pshir...@boosthardware.com> wrote: > > > > > > > > > > We have several headless machines running GPU's with thousands of > > processing units available. Much more power than the first "Lord of the > > Rings" movie was made with. > > > > > Still worth exploring though, and a "cl~" processor for my system is > > > definitely on the todo list. > > > > > > > We are exploring the possibilities here too. Essentially a library that > > allows sending specific operations across a netjack cluster for realtime > > multimedia processing. > > > > you might want to check the latency before you get too far into plans like > this. i've heard that it is improving, but still not really what one would > expect of a "realtime FX processor". Indeed. Crazy throughput, but transferring to and from the GPU kills you. Worth investigating anyway since many-core is probably going to stick around and become faster, but I doubt current GPUs can achieve reasonable real-time audio latency. I think the programmable GPUs on recent Intel chips (Ivy Bridge) is an interesting development; though much less powerful and far less cores, they have full memory bandwidth (the other thing that kills you), and presumably minimal latency since it's on-die. Adding 8 or so cores may not be in the same realm as adding hundreds, but for many things the latency and memory bandwidth dominates anyway so a billion cores on a GPU would still be slower. Anything memory bound is much slower even on the best GPUs. I'll happily take 8 extra cores on the CPU... Unfortunately they're not programmable on Linux yet, only on Windows. A complete joke if they're targeting scientific GPGPU, and useless for LAD too. Intel seriously needs to get on this and fix their drivers... -dr signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, 2012-12-11 at 02:56 +1100, Patrick Shirkey wrote: > On Mon, December 10, 2012 10:42 pm, Bill Gribble wrote: > We have several headless machines running GPU's with thousands of > processing units available. Much more power than the first "Lord of the > Rings" movie was made with. Good stuff to have available! Even on a normal laptop with external GPU chipset and the builtin Intel one too there's a pretty powerful idle processor. That's why I started getting interested. Also, I penciled out a hardware setup that would allow a laptop to add external PCI graphics cards for this purpose, seems like a great choice for convolution reverbs, long FIR filters for linear-phase EQ, etc. I mention interactions because there are a few commercial GPU-accelerated audio plugins for Windows (convolution reverb was all I could find, can't remember the name offhand), and I spent some time scraping forums at the manufacturer, gearslutz, etc for information about real-world performance. The reports were that the latency for executing OpenCL kernels was pretty unpredictable, and seemed to be related to resource allocation by the desktop OS. Not an issue in your case, nor in any case where you have a dedicated chip (or render farm) for your own purposes. Thanks, Bill Gribble ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey < pshir...@boosthardware.com> wrote: > > > > > We have several headless machines running GPU's with thousands of > processing units available. Much more power than the first "Lord of the > Rings" movie was made with. > > > Still worth exploring though, and a "cl~" processor for my system is > > definitely on the todo list. > > > > We are exploring the possibilities here too. Essentially a library that > allows sending specific operations across a netjack cluster for realtime > multimedia processing. > you might want to check the latency before you get too far into plans like this. i've heard that it is improving, but still not really what one would expect of a "realtime FX processor". ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Mon, December 10, 2012 10:42 pm, Bill Gribble wrote: > I have done some proof of concept tests with pyopencl that look > interesting. > > There are practical problems: you add a whole other "domain" to process > in, in addition to Python-world and Jack-world. You have deployment > issues with the OpenCL libs for different GPU vendors. The wide SIMD > architecture of GPUs is really only helpful for certain audio ops like > convolution, or very wide banks of identical processing. And if you are > using the card for graphics, there may be unpredictable interactions. > We have several headless machines running GPU's with thousands of processing units available. Much more power than the first "Lord of the Rings" movie was made with. > Still worth exploring though, and a "cl~" processor for my system is > definitely on the todo list. > We are exploring the possibilities here too. Essentially a library that allows sending specific operations across a netjack cluster for realtime multimedia processing. > Thanks, > Bill Gribble > > On Dec 10, 2012, at 6:19, "Patrick Shirkey" > wrote: > >> >> On Mon, December 10, 2012 9:06 am, Bill Gribble wrote: >>> Patrick, interesting stuff! I am about to push an early version of my >>> current project to github -- python and clutter implementing a puredata >>> knockoff (with python data types and evaluator). >>> >>> I've found it to be a good combo so far, using multiprocessing to >>> separate >>> engine, UI, and DSP (in C extension). >>> >> >> >> That is my experience with the combination too. I have also found it >> works >> nicely as an addition to a gtk3 interface using the embed() option. That >> gives a gtk3 wrapper with direct cairo support while allowing easy >> access >> to clutter, opengl and the advanced gesture and animation support. It's >> a >> pretty powerful combo. >> >> One thing I am still working on is getting direct access to the GPU for >> additional processing grunt. >> >> >> >> >>> Thanks, >>> Bill Gribble >>> >>> On Dec 9, 2012, at 16:20, "Patrick Shirkey" >>> >>> wrote: >>> On Mon, December 10, 2012 3:37 am, Louigi Verona wrote: > Hey Patrick! > In what way would you say this is different from JACK Keyboard? First it uses alsa midi through the alsaseq library. Second it is written in python3. Third it uses the Clutter "opengl" UI toolkit. I'm not sure if jack keyboard supports 128 midi keys. CMKeyboard is not intended to replace jack keyboard. It's about getting some traction using Python3 and Clutter. Clutter and Python are two under utilised options in LAD. Not sure why Python is not so popular considering how many professional and highly successful AV projects have been built with it but Clutter seems to have been off the radar for a while. Maybe now that the new touch interfaces are arriving in the market this year we will see a pick up in Clutter projects for LAD applications. > On Dec 9, 2012 7:28 PM, "Patrick Shirkey" > > wrote: > >> Announcing CMKeyboard - Clutter MIDI Keyboard >> >> http://djcj.org/cmkeyboard >> >> CMKeyboard is a 128 note ALSA MIDI virtual piano keyboard spanning >> from >> C-1 to G9 written in python3 and taking advantage of the latest >> Clutter >> (>1.12.2) features to enable scrolling and opengl goodness. It is a >> stand >> alone program which can also be embedded into other python3 >> applications >> as a class library. It uses code from the very handy >> pyclutter-widgets >> project for the rounded rectangles of the key buttons. >> >> The code demonstrates use of Clutter.ScrollActor(), >> GtkClutter.Embed(), >> layering of multiple clutter actors, handling of events including: >> "button-press-event" & "key-press-event". >> >> Suggestions for features and improvements welcome. >> >> >> Enjoy! >> >> >> -- >> Patrick Shirkey >> Boost Hardware Ltd >> ___ >> Linux-audio-dev mailing list >> Linux-audio-dev@lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev >> > -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user >>> >> >> >> -- >> Patrick Shirkey >> Boost Hardware Ltd >> ___ >> Linux-audio-user mailing list >> linux-audio-u...@lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-user > -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
