Re: segfaults, working version?

Hi Michael :)

comments inline...

On 06/21/2010 02:19 PM, notzed [via jogamp] wrote:

All,

I was moving some stuff to a different machine and downloaded a different jogl/etc than last time because I can't remember where I got the other one (and that was x64 so I couldn't use it) ...  Anyway, it has the nicer object based api, so I converted the minimal code I have over to use it.

But .. it just crashes pretty consistently when executing some simple kernels with "Java Result 139".

could you provide a testcase so I could try to reproduce the crashes? Small as possible so we can add it to the unit tests... would be cool.

if you are using JOGL:
please call GLProfile.initSingleton() before doing any UI work. This changed recently to enable some threading optimizations. We try to get rid of this workaround somehow.

And even when it doesn't, odd things happen like data seemingly not making it to the buffers by the time I use them - I converted a bastardised version of the 'simplemandelbrot' demo I found at http://www.jocl.org/samples/samples.html to the new api and 9 times out of 10 I get a blank result, and at best a few inconsistent pixels around the mandelbrot curve show up (but that indicates the kernel is at least executing).

looks like a missing queue.finish() or queue.readFoo(..., blockingread=true,...); at the end of the computation. But difficult to tell without taking a look at the code... (this could even cause the segfaults above).

I believe all callbacks were disabled in this build, so please don't use them for now if possible.

I'm using the one from here: http://jogamp.org/deployment/autobuilds/jocl-2010-06-16_12-21-31/, with jogl-2.0-pre-20100616-linux-i586.zip on linux x86, with the ati stream sdk 2.1, and still just using the cpu device so far.  I've tried the sun jdk 1.6.0_20 as well as an older openjdk.

I guess i'm asking - is this stuff at a stage it is expected to be usable and i'm simply stuffing things up (the 'hellojocl' demo works), is it premature to be playing with it, and/or is there a version I should be using and is known to work ok?

we have several junit tests covering a big part of the OpenCL api which are run basically after each commit on at least 5 machines. The CL core binding looks stable so far.

There is also a linux related driver bug worth mentioning. For a workaround, start your program from console and enable signal chaining with:
export LD_PRELOAD=/usr/lib/jvm/java-6-sun/jre/lib/amd64/libjsig.so
The bug was only reproducible with NV drivers so far (which is fixed in the upcoming driver release) but it could happen on AMD too...
(in short: some drivers replace mandatory JVM signal handlers which leads to crashes and very unstable behavior esp in GL-CL interop. apps.)

Regards,
 Michael

hope that helps,

Regareds,
Michael Bien

---

View message @ http://jogamp.762907.n3.nabble.com/segfaults-working-version-tp911276p911276.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

Hi Michael,

I deleted the original message on nabble forgetting this is a mailing list ... The crashes were all down to some rather embarrassing (mis)use of Buffer objects and a few pokes later I got my stuff to run.  My patience had prematurely run out it seems ...

No crashes anymore, but the Mandelbrot isn't really working still - colourmap seems to be off, and usually all black.  So it might just be a java-side issue.  I've made a bit of a pigs breakfast of the source, but if you would find it useful I can probably clean it up a bit to make another `hello world' example (if you don't have it converted already).

Thanks for the other info, not using jogl yet but will eventually.

 !Z

Michael Bien wrote

Hi Michael :)

comments inline...

On 06/21/2010 02:19 PM, notzed [via jogamp] wrote:
> All,
>
> I was moving some stuff to a different machine and downloaded a
> different jogl/etc than last time because I can't remember where I got
> the other one (and that was x64 so I couldn't use it) ...  Anyway, it
> has the nicer object based api, so I converted the minimal code I have
> over to use it.
>
> But .. it just crashes pretty consistently when executing some simple
> kernels with "Java Result 139".
could you provide a testcase so I could try to reproduce the crashes?
Small as possible so we can add it to the unit tests... would be cool.

if you are using JOGL:
please call GLProfile.initSingleton() before doing any UI work. This
changed recently to enable some threading optimizations. We try to get
rid of this workaround somehow.

[...]

On 06/22/2010 07:49 AM, notzed [via jogamp] wrote:

Hi Michael,

I deleted the original message on nabble forgetting this is a mailing list ... The crashes were all down to some rather embarrassing (mis)use of Buffer objects and a few pokes later I got my stuff to run.  My patience had prematurely run out it seems ...

no problem. good that it works for you. nice.

No crashes anymore, but the Mandelbrot isn't really working still - colourmap seems to be off, and usually all black.

are we now talking about this demo?
http://github.com/mbien/jocl-demos/blob/master/src/com/jogamp/opencl/demos/fractal/MultiDeviceFractal.java

it works on all systems and drivers i tried so far. Maybe its a pixelformat issue or so (it uses GL-CL interoperability).

 So it might just be a java-side issue.  I've made a bit of a pigs breakfast of the source, but if you would find it useful I can probably clean it up a bit to make another `hello world' example (if you don't have it converted already).

we have already a fractal demo (mentioned above). But sure contributions are always welcome. If you find somewhere a cool demo to convert... sure (e.g i converted the julia3d demo from c to java). But please check the license, jogamp projects are all BSD.

Thanks for the other info, not using jogl yet but will eventually.

 !Z

Michael Bien wrote:

Hi Michael :)

comments inline...

On 06/21/2010 02:19 PM, notzed [via jogamp] wrote:
> All,
>
> I was moving some stuff to a different machine and downloaded a
> different jogl/etc than last time because I can't remember where I got
> the other one (and that was x64 so I couldn't use it) ...  Anyway, it
> has the nicer object based api, so I converted the minimal code I have
> over to use it.
>
> But .. it just crashes pretty consistently when executing some simple
> kernels with "Java Result 139".
could you provide a testcase so I could try to reproduce the crashes?
Small as possible so we can add it to the unit tests... would be cool.

if you are using JOGL:
please call GLProfile.initSingleton() before doing any UI work. This
changed recently to enable some threading optimizations. We try to get
rid of this workaround somehow.

[...]

---

View message @ http://jogamp.762907.n3.nabble.com/Re-segfaults-working-version-tp911744p913447.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

On 22 June 2010 17:52, Michael Bien [via jogamp]
<[hidden email]> wrote:
> On 06/22/2010 07:49 AM, notzed [via jogamp] wrote:

> no problem. good that it works for you. nice.

Well thanks for a nice api.

> are we now talking about this demo?
> http://github.com/mbien/jocl-demos/blob/master/src/com/jogamp/opencl/demos/fractal/MultiDeviceFractal.java
>
> it works on all systems and drivers i tried so far. Maybe its a pixelformat
> issue or so (it uses GL-CL interoperability).

No, just this one which uses bufferedimage's:
http://www.jocl.org/samples/JOCLSimpleMandelbrot.java

> we have already a fractal demo (mentioned above). But sure contributions are
> always welcome. If you find somewhere a cool demo to convert... sure (e.g i
> converted the julia3d demo from c to java). But please check the license,
> jogamp projects are all BSD.

I find the jogamp web pages are a little obtuse and difficult to
navigate at the moment and so I only saw the one on the 'hellojocl'
page so it didn't seem you had many demos.  But there's no point in
another simple mandelbrot (although i'd be personally curious if
vectorising it would make a difference).

If I see/come up with something interesting i'll see about doing a
demo, but i'm just getting up to speed at the moment.

 !Z

While using JOCL, I get segfaults left, right and center. If I initialize a context and load a program in it but do not use it, it crashes after a while. If I use it, it also crashes.

These are my first steps towards programming for the GPU, and I only wish to multiply large vectors, this is still a strange issue to me. Note that I only initialize the context and don't even do something with it and it already crashes...

However, I created one of the example programs (multiply vector) and that worked, but it ran so quickly it hardly had the time to crash... I'm not sure which driver versions I use, how to find that out in ubuntu?

Also, may there be some conflict between my X session and JOCL? Using the C/C++-examples my system sometimes hangs (except the mousepointer?!).

Merijn Vogel wrote

While using JOCL, I get segfaults left, right and center. If I initialize a context and load a program in it but do not use it, it crashes after a while. If I use it, it also crashes.

These are my first steps towards programming for the GPU, and I only wish to multiply large vectors, this is still a strange issue to me. Note that I only initialize the context and don't even do something with it and it already crashes...

However, I created one of the example programs (multiply vector) and that worked, but it ran so quickly it hardly had the time to crash... I'm not sure which driver versions I use, how to find that out in ubuntu?

Also, may there be some conflict between my X session and JOCL? Using the C/C++-examples my system sometimes hangs (except the mousepointer?!).

nvidia driver?

see:

Michael Bien wrote

There is also a linux related driver bug worth mentioning. For a workaround, start your program from console and enable signal chaining with:
export LD_PRELOAD=/usr/lib/jvm/java-6-sun/jre/lib/amd64/libjsig.so
The bug was only reproducible with NV drivers so far (which is fixed in the upcoming driver release) but it could happen on AMD too...
(in short: some drivers replace mandatory JVM signal handlers which leads to crashes and very unstable behavior esp in GL-CL interop. apps.)

(but newest binary nv drivers fixed this issue)

if its not signal chaining please provide a small testcase which reproduces the issue.
also take a look at the junit tests if you want to know how to read out driver information etc:
http://github.com/mbien/jocl/blob/master/test/com/jogamp/opencl/HighLevelBindingTest.java
(e.g. contextlessTest)

-michael

On 08/26/2010 02:05 AM, Merijn Vogel [via jogamp] wrote:
>
> Also, may there be some conflict between my X session and JOCL? Using
> the C/C++-examples my system sometimes hangs (except the mousepointer?!).

ubuntu has usually compiz enabled which is basically a fully hw
accelerated windowmanager. If you put load on the GPU via OpenCL its
quite possible that windowing gets less responsive. Depends on your
driver and GPU and the load. ... its not a bug.

--
http://michael-bien.com/

Thanks for the replies, I had disabled compiz (appearance -> visual effects -> none) to free up the resources. I've only got an GeForce NVIDIA GT240, lspci:

01:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GT 240] (rev a2)

The nvidia driver was built from this version:
/usr/src/nvidia-current-195.36.24

Is that recent?

thanks,
Merijn

no its not. Just check the NV website.

On 08/26/2010 07:59 AM, Merijn Vogel [via jogamp] wrote:

Thanks for the replies, I had disabled compiz (appearance -> visual effects -> none) to free up the resources. I've only got an GeForce NVIDIA GT240, lspci:

01:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GT 240] (rev a2)

The nvidia driver was built from this version:
/usr/src/nvidia-current-195.36.24

Is that recent?

thanks,
Merijn

---

View message @ http://jogamp.762907.n3.nabble.com/Re-segfaults-working-version-tp911744p1346212.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

-- 
http://michael-bien.com/

The installed driver seemed to be 256.40, it's now 256.44.
That 195.something source was apparently old. For me it was 2am last night that I asked you, so thanks for the tip and I'll keep trying.

It's still unstable, I'll try to create an isolated algorithm that misbehaves soon, so someone who likes to help can point out the "obvious" mistake I make.

Merijn Vogel wrote

The installed driver seemed to be 256.40, it's now 256.44.
That 195.something source was apparently old. For me it was 2am last night that I asked you, so thanks for the tip and I'll keep trying.

It's still unstable, I'll try to create an isolated algorithm that misbehaves soon, so someone who likes to help can point out the "obvious" mistake I make.

I tell you what, the Nvidia stuff is shit, don't believe the hype about how their 'software is so much better'.

I managed to get a relatively stable setup using the beta driver (258.19) but to be honest it's still not fantastic.  I'm simulating processing 'real time' video using a throttled feed from disk and if I turn off the throttle it generally crashes within seconds.  The crappy profiling tool crashes even with the delayed processing (on microsoft's system as well).  I think it's just luck that the app is stable at this point - which I don't feel too comfortable about as I continue to develop it.  It was relatively stable with an older driver too (even with the jvm interaction bug and lots of bugs in my jocl side code) until I added some more processing.

Although I think i'm doing things right (especially wrt threading) I wouldn't put it past a bug in my code either, but you really just can't tell from the instant-death-segfault in the jvm what's going on.

Oh I also have to do the JOGL initSingleton() thing even though i'm not using JOGL yet ...