About Me

Michael Zucchi

 B.E. (Comp. Sys. Eng.)

  also known as Zed
  to his mates & enemies!

notzed at gmail >
fosstodon.org/@notzed >


android (44)
beagle (63)
biographical (104)
blogz (9)
business (1)
code (77)
compilerz (1)
cooking (31)
dez (7)
dusk (31)
esp32 (4)
extensionz (1)
ffts (3)
forth (3)
free software (4)
games (32)
gloat (2)
globalisation (1)
gnu (4)
graphics (16)
gsoc (4)
hacking (459)
haiku (2)
horticulture (10)
house (23)
hsa (6)
humour (7)
imagez (28)
java (231)
java ee (3)
javafx (49)
jjmpeg (81)
junk (3)
kobo (15)
libeze (7)
linux (5)
mediaz (27)
ml (15)
nativez (10)
opencl (120)
os (17)
panamaz (5)
parallella (97)
pdfz (8)
philosophy (26)
picfx (2)
players (1)
playerz (2)
politics (7)
ps3 (12)
puppybits (17)
rants (137)
readerz (8)
rez (1)
socles (36)
termz (3)
videoz (6)
vulkan (3)
wanki (3)
workshop (3)
zcl (4)
zedzone (26)
Wednesday, 05 March 2014, 12:41

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:

  1. 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.

  2. 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.

Tagged hacking, java, javafx, opencl, parallella, rants.
cheapo amp | zcl 0.2 released
Copyright (C) 2019 Michael Zucchi, All Rights Reserved. Powered by gcc & me!