10 Dec
2012
10 Dec
'12
4:56 p.m.
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" <pshirkey(a)boosthardware.com>
wrote:
--
Patrick Shirkey
Boost Hardware Ltd
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"
<pshirkey(a)boosthardware.com>
wrote:
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
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"
> <pshirkey(a)boosthardware.com>
> 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(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10 Dec
10 Dec
5:12 p.m.
On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey <
pshirkey(a)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".
5:33 p.m.
On Mon, 2012-12-10 at 11:12 -0500, Paul Davis wrote:
On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey
<
pshirkey(a)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
7:40 p.m.
On Tue, December 11, 2012 3:33 am, David Robillard wrote:
On Mon, 2012-12-10 at 11:12 -0500, Paul Davis 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.
On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey
<
pshirkey(a)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
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.
Rings" movie was made with.
that
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 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". 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
7:46 p.m.
On Mon, Dec 10, 2012 at 1:40 PM, Patrick Shirkey <pshirkey(a)boosthardware.com
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.
9:29 p.m.
On Tue, 2012-12-11 at 05:40 +1100, Patrick Shirkey wrote:
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)
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
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? 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.
10:46 p.m.
On Tue, December 11, 2012 7:28 am, David Robillard wrote:
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
On Tue, 2012-12-11 at 05:40 +1100, Patrick Shirkey
wrote:
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...
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? 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. 
5:33 p.m.
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
11 Dec
11 Dec
12:25 a.m.
On Tue, December 11, 2012 3:32 am, Bill Gribble wrote:
On Tue, 2012-12-11 at 02:56 +1100, Patrick Shirkey
wrote:
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.
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.
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
4162
days inactive
4162
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Bill Gribble -
David Robillard -
Patrick Shirkey -
Paul Davis