Strange surprise for the day.

  linaro-ubuntu-desktop:~/src/zcl> PATH=/usr<tab>
  PATH=/ not found

Hmmm?

  linaro-ubuntu-desktop:~/src/zcl> echo $SHELL
  /bin/tcsh
  linaro-ubuntu-desktop:~/src/zcl>

tcsh? Oh wow. Weird. People still use that? Actually I know a sysadmin who still uses it but he still thinks SunOS 4 was the epitome of operating systems and he wont touch GNU/Linux with a barge pole (SomeBSD all the way for him). And yeah i'm also a little glad he doesn't admin anything i use ;-) Just teasing, although i'm a little baffled how he can do his job effectively without Bourne Shell scripts.

It's been so long it slipped my mind that '> ' implies a user-login csh when I saw the different prompt on the 131224 build of the parallella os. I think the last time I used tcsh was when I was at uni (20 years ago) until GNU/Linux pretty much forced me to use bash. Which i'm glad of because not only is it easier to learn and use, it's also more consistent and powerful.

Each to their own I guess/stranger things have happened/easily fixed, but still a surprise.

I should be out enjoying another unseasonally hot autumn day but following insufficient sleep after crashing rather late following a visit to friends yesterday arvo it's all a bit too hard. So i'm just having a quick poke at OpenCL on parallella again although some more sleep isn't very far off.

...

So I just now discovered something that means I messed up a bit. The 131224 OS looks to be the same linaro version with the same sdk as the previous image I was using. It's just using a different uboot, linux, and configured to start more desktop stuff. Or in other words all the stuff I changed or removed yesterday ... But more importantly it means the whole point of the exercise was missed: the binary dist of coprthr still isn't going to work.

Oops, well now don't i feel like a bit of a drop-kick. That was a good waste of a couple of afternoons so it might be a good idea to leave that topic for a bit and try a different approach next time.

Maybe revisit the elf-loader code I was experimenting with but work on creating a way of accessing it from Java. I have no trouble with C or even ASM hacking but writing a GUI in C or even touching C++ isn't something I'm going to do for fun and processing pam files from a command line isn't very interesting. Having an esdk analogue for Java could be quite useful actually now I think about it.

Otherwise I'm probably going to have to bite the bullet and work on setting up a dev env on my workstation.

cheapo amp

After i blew my AVR/amp a few months ago i've just been using my tv to play music. It's got a screen-off mode but yeah it's not ideal - particularly with the standby power saving thingo that turns it off after a few hours because it's not drawing enough power to indicate it's on.

That amp was about $2K so this time I thought i'd go all cheap and buy what I presume is a d-class amp just to see how it works. I was going to buy a PCB module to play with but I know i'll never have the time to case it properly. I find amplifier technology pretty interesting from a technical perspective and digital amps in particular (the way they work and their efficiency).

I got one of these. FWIW I don't think i'll use "audirect" again to order anything, it just seems to get lost in deal-extreme's ordering system which is still just in china anyway. Actually I was a bit drunk when I ordered it so I got 2 (well I have a 4 speakers + a centre) and the second is the model with the usb input mp3 player which hasn't arrived yet. Yeah I don't know what I was thinking with that, but maybe it'll come in handy or at least doesn't affect the amp part if I plug it into something else.

Anyway ... yeah it's tiny - it's not as deep as a DVD case is wide either. It's about the same size as my mele. It came with a small laptop power brick that's about the same size as the one for my thinkpad. It's marked 19v @ 3.42A so that's a 65W PSU which is clearly not enough for "100W" no matter what ohmmage the speakers are! Probably the spec of the amp chip I guess. Still amp power has always been fraudulently advertised so there's no surprise here.

My VAF speakers although a bit long in the tooth are pretty sensitive so it puts out enough volume for a suburban house and I managed to burn one out with my old amp so i don't really want too much anyway. I've got it plugged into the mele and am using it as an internet radio player for the moment. I tried it plugged it into the tv monitor output but for some stupid reason the tv sends the signal after it has been through the volume control so it wasn't any good as a line-out (maybe i had the wrong output, it's hard to get to). I didn't try the headphone output.

I haven't run it very loud for very long but I had it running for a few hours yesterday at about as loud as I might want it while working. After that the box itself was stone cold although the PSU was only a little warm (much cooler than my thinkpad) so I guess it wasn't using many watts.

I'm sure the sound isn't going to win any audiophiles over but i'm not sure their opinion is worth much either. It's more bassy than my old amp which isn't a bad thing although it seems a bit harsh in the mid frequencies when I turn it up, but loud things are harsh so it's hard to tell what's to blame. Could also just be the signal, mp3 artifacts becoming audible, tired speakers, or just the gyprock box of a room it's in.

Not sure i'd recommend it to anyone else but for now it saves me having to get something better and i had a reasonable idea what i was getting.

I just got a mail about my contract restarting soon. Well to be honest I was getting a bit bored with life as a 'man of leisure' but that doesn't mean I wanted it to end either. But I suppose that crust wont earn itself. Good reason to get away from this thing for a bit and get out into the fantastic autumn weather we've been having anyway. Off to buy a new bike tyre and then find some cold beer.

PS I just read the back of the box. One of the better* engrish translations I've read in a while.

  Products  throughout  the  sound  system  components  using  the United  States imported
  high precision components, static,  dynamic  output digital audio  signal  waveform  is
  ideal, the  sound  is really beautiful!Digital power amplifier, sound, very resistant to
  high  and low frequency balance,  control force quite amazing,  sweet voice soft, medium
  thick warm, low frequency driving, high frequency resolution is very high and the soft
  linear flavor, the sound very melodious, very resistant to. Listen to the modern style
  of music performance is very outstanding also does not appear harsh, just feel  very clear
  transparent, maintain one's original pure character. Listen to  the violin to restore enough
  soft enough soft, let tweedle to maintain a proper and just bright luster, but also can be
  the powerful piano keystroke behaved most in cisive,  great sense of shock; listen to  the
  orchestral music with various  musical instruments to further improve the texture,  can
  exhibit a  woodwind instrument  soft delicate texture,  also can let a  brass instrum ent the
  sound  become more and more high and clear. With high sensitivity to sound better!  Playing
  soprano light, sweet moisture, melodious sound,  very resistant to. Application: automotive,
  mobile advertising, clothing store,  barber shop, recreation, library, business super,  home
  theater,  factory workshop,  compact, simple,  high-quality  sound system  solutions, etc..Can
  external audio input.  you can connect the computer, mobile phone, CD, VCD, DVD, MP3 digital
  audio signal input......

Spacing as in the original but formatted for screen.

* worse.

Update: Just has the other one delivered. At first I couldn't seem to get any sound out of it ... but it turns out that it just isn't very loud - nothing comes out until you're about 50% position. It also uses small press connectors rather than banana plugs - I really should've looked at the pictures when I ordered.

It uses a different PSU too - 4A @ 12V (48W). Other differences are that the volume is also a power knob - although it's got a pretty nasty speaker-pop when you turn it off. The pots are a bit more greased up so they feel a bit more solid to touch which whilst cosmetic does make a difference. Has bass and treble (why?). The input selector toggle on the back seems to be mounted backwards but that is neither here nor there. The USB port is in an inconvenient place relative to the buttons. Might have to get one of those super-short USB memory sticks.

Verdict: The one with the mp3 player isn't worth it as I kinda suspected once I sobered up. Not really loud enough, mp3 player is a tricky because of the button locations and the speaker pop-off is not good.

I guess I lucked out a bit on that one. Still better than the shitty pc speakers or music-angels i've been using so I it's not a total waste.

Update 2: Ok I tried the remote. You can get a (tiny) little bit more volume out of it. And it's got an 'EQ' button which makes the bass/treble knobs redundant (i.e. where the usb port should have been). And a standby mode which stops blowing your speakers with the pop-off thing. I was gonna move my rears into the kitchen/dining area (approx rectilinear 7.5mx6mx3m room with an internal passage-way to the dunny) so it should more than suffice for my purposes and being in the same room means i don't need so much volume anyway. I suppose it's about as loud as I might listen to music whilst working (enough to drown out everything outside from trucks to chainsaws) but not loud enough to dance to (although perhaps the less said about that the better). Should do well with some wine and good mates.

Still probably wouldn't recommend since there are better ways to get sound into speakers than a usb port (e.g. phone, tablet, music player, pc, tv - maybe i can find a use for a spare beagleboard). But i'm happy enough with the bare-bones approach of other one so far.

opencl javafx mandelbrot thingy

I didn't want to think too much coming up with something to test my opencl binding so I took the mandelbrot demo code from the parallella opencl forum and ported it to JavaFX and zcl. Aim is to try it on the parallella but i'm having troubles with the opencl environment so I just did it on my new workstation.

Because I was too lazy to do a full 'explorer' I just converted it to a julia-set generator and use the mouse location to set the seed point.

Using the gpu it easily keeps up with the screen refresh even at 4x this resolution (1024x1024). The julia set escapes much faster than the mandelbrot set so even the cpu driver can keep up quite well actually until you hit the blobby empty areas. I'm using a kaveri 7850 APU and the above image is about 100-200uS on the gpu and about 3mS on the cpu driver according to the profiling timestamps.

At first I was a little stumped as to how to hook the rendering into the JavaFX refresh. But I came up with a couple of approaches:

Use a never-ending Transition.
Each time the interpolate method fires it checks to see if the last rendering has finished and if it has it fires off another rendering (and event) and copies the pixels to the WritableImage.
Use an event callback.
When the job is queued, add an event callback for when the output event reaches the CL_COMPLETE state. When it fires queue a copy to the WritableImage using Platform.runLater() and at the same time enqueue a new render.

The former hits the sort of rendering issues you get from double-buffering (if it's not fast enough it jumps to half speed) although it loads the system quite lightly and does a lot less mucking about with cross-thread invocation.

I wonder if you can efficiently triple-buffer with JavaFX? I guess render to a non-attached WritableImage from another thread and dump it into the ImageView at the next pulse? Maybe sort of.

Of course ... it would be better if the OpenCL just wrote directly to the GL texture, ... but I guess we can't have everything we want right away.

The code is too ugly to publish and it's not like the world needs another one of these demos but if i ever get opencl working on the parallella i'll drop it somewhere.

Software "upgrades"

Yes, scary quotes.

On to a short rant. As part of this post I needed to get a screenshot. No worries I says, fire up the gimp as usual, grab a screenshot, save it for blogger as png. Oh, it wont let me. What the hell? Why would I want to save in xcf unless I wanted to save in xcf? Bizarre.

Seems there's a whole ocean of complaints about this one I've managed to avoid until now because I so rarely re-install my operating system. The whole thing about not wanting "normal" users is pretty fucked up though. Who the hell do they think is going to use it then, Hollywood? And if so - why the fuck are they pandering to those DRM-eye-pee-bullshit bastards in the first place? Free software gone mad. Effectively forked from it's mission by it's own bully developers and yes-men cronies. Krita looks a bit too hip for my tastes but I suppose it's worth a look (yeah, i'm probably not going to poke at ImageZ again, although, you know, opencl + javafx could be a 'thing' there).

I'm sure i've mentioned this many times but in part i think it's just that nobody wants to 'just maintain' fully mature software and they have to keep poking at it just for the sake of it. And new blood always wants to make it's mark - and there's no wiser hands left to stop them. And no doubt they've caught a bit of the software-treadmill disease from M$ or apple since that's what they were brought up with. Not to mention this whole rolling-upgrade-never-ending-changes bullshit that mozilla and google are so fond of. I had reason to go to the australian acma website yesterday (robot caller kept calling back every half hour - which is apparently completely legal ... sigh ... and given it was polling political data for the upcoming state election we have no hope of the pollies doing anything about it) and I was absolutely astounded at how shitty and difficult to use it has become. Obviously a M$ weenie is in the design driver's seat because the whole front page is a huge mess of metro-inspired animating vomit.

It's no wonder i'm so averse to "upgrading" my gnu/linux install. Every time there's some piece or even whole suite of software which is just that little bit more fucked up and harder to use than the previous version. I gotta spend half a day just getting the defaults usable again and it's weeks before everything is sorted (e.g. like this gimp surprise). It even keeps happening to emacs of all things (visual line mode - i mean really?) and gcc (well the C standards) can't seem to agree on what is worth a warning from version to version.

zcl 0.2 released

Details on zcl home page but the main thing is that it now builds on parallella and with OpenCL 1.1 (and presumably other 32-bit platforms).

Doesn't seem to work as per the previous post, but it builds.

parallella + java + opencl = not happy jan

So following the previous post I thought i'd try getting zcl running on the parallella. I can't really think of anything to use it for but I thought maybe a javafx frontend to a opencl-something would do for an experiment and I haven't used the machine for months and feel a bit like I should.

I had to fix some 32-bit issues and also discovered some api bits missing but the main work was getting zcl to support an OpenCL 1.1 backend since unfortunately coprthr only supports OpenCL 1.1 at the moment. Rather than pollute the api I kept the Java API the same and emulate the various functions where possible through the 1.2 interfaces (e.g. clCreateImage calls clCreateImage2D/3D as appropriate) or throw an UnsupportedOperationException for new functionality. I fixed some other issues as logged on the downloads page.

So I compiled it and linked it to libocl instead of libOpenCL.so (the first surprise), compiled up some pre-requisites for coprthr ... and yeah it just crashes in loadLibrary(). Bummer.

It's most likely that my disk image is out of date I was just hoping to avoid a whole sysadmin session just to poke at some software. I'm kinda over that shit these days.

Update: See the follow-up post where I got it working. It was just a library versioning issue. The OpenCL stuff is a little 'rough' IMNSHO, but it should still be possible to do real work with it too.

zcl 0.1 released

Just wanted to get it out of the way so I did a bit of house-keeping on my isp web page and created a zcl home page. It pretty much explains everything that could be said here.

As part of the house-keeping I created a basic but functional software index page to consolidate the mess of stuff I had there and moved all the download files to a common location.

Update: I went looking for that option that turns on warnings for functions without prototypes ... and found a bug. enqueueReadImage() can't work in 0.1.

Anyway I found something to do: get it going on parallella.

toArray or not to array

So I guess I found some more stuff to play around with. It's a really lovely day here but I know town is going to be packed a bit more than I'd like and I've kinda had enough of going out for the moment. I guess i'll see after lunch on that.

First I thought i'd fix the array getter methods. The OpenCL get methods are built in a way where if you don't know the size of a field you have to call it twice - once to get the size and the next to get the content. There didn't seem to be much point exposing this to the Java side of things as I had initially done and I went with just doing that directly in the C code and returning a newly allocated and correctly sized result. My original thoughts were that perhaps buffers could be re-used for multiple gets but in reality it just isn't that useful: for small buffers it doesn't matter and for large ones you need to find out the size anyway and any management overheads (thread-specific etc, and simply having memory sitting around doing nothing) of reusable buffers is going to swamp allocation and GC.

I also realised I could fix one of the last bastions of the exposed native pointers and change the long getInfoP methods to return an object directly to:

 native public <T extends CLObject> T getInfoP(int param, Class<T> klass);

Which is kind of nice. Actually getInfoP() was hidden by type-specic getters but doing it this way (and particularly for the array types) saved even more code in the Java side for a minimal cost on the C side (actually I ended up saving code by reorganising the array getters).

Then I thought about whether I could add native array types to the CLCommandQueue interfaces. e.g.

    native public void enqueueReadBuffer(CLBuffer mem, boolean blocking,
        long mem_offset, long size,
        byte[] buffer, long buf_offset,
        CLEventList wait,
        CLEventList event) throws CLException;

In addition to the interface that uses nio buffers.

The tricky bit is that these can run asynchronously so you can't use the GetPrimitiveArrayCritical() calls and you're basically left with either manually copying them using Get*ArrayRegion() or using Get*ArrayElements() which just seems to copy them on hotspot anyway.

As an experiment I tried the latter. Actually it ends up copying both ways which is a bit of a waste.

When called without blocking I use an event callback to await completion and then release the array back to Java. Strictly speaking I should also do the same for the Buffer versions so that the Buffer doesn't get GC'd while it's running but that's something I think can be left to the programmer to keep track of.

I tried a test program which just did many calls followed by a flush each time and actually performance wasn't too bad relative to the Buffer version. Maybe 10-20% slower (which is ok since accessing arrays is faster and simpler than Buffers in java). But then I tried a silly example of moving the flush outside of the loop. Ok, now it's 4x slower and god knows how much memory it ends up swallowing whilst executing.

So I followed up by trying the GetArrayRegion interface. This is a little bit faster but nothing to write home about.

At this point I think i'll just keep the binding and api smaller and leave it with using a ByteBuffer (sigh, which i still need to fix the endianess of) but i'll save the code for maybe later.

Actually probably the most surprising thing is just how slow the OpenCL stuff is here. This is only using the CPU driver so there's no weird memory busses to go over (even if this wasn't an apu). It's about 100x slower than copying a ByteBuffer to a byte array the same number of times. I thought it might be because the calls are non-blocking, but making them blocking only makes it worse. I tested the JNI overhead too by simply nooping out the clEnqueueReadBuffer call on the array Region version and that is only about 2x slower than ByteBuffer.get().

Yeah ...

About Me

Tags