jogamp › jogl

method not implemented: gluScaleImage

Classic

List

Threaded

18 messages Options

OwenD

method not implemented: gluScaleImage

We are in the process of upgrading our applications from JOGL1 to JOGL2. One issue we've run into is the following error (I'm using autobuild b266):

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: not implemented
at javax.media.opengl.glu.GLU.gluScaleImage(GLU.java:1479)

Is there something in particular in the profile/capabilities initialization which must be done to enable gluScaleImage? Should I add an enhancement request to bugzilla?

Thanks.

Michael Bien

Re: method not implemented: gluScaleImage

try GLUgl2.

but feel free to file a bug/enhancement. we should use a better error message.

regards,
michael

On 01/21/2011 09:56 PM, OwenD [via jogamp] wrote:

We are in the process of upgrading our applications from JOGL1 to JOGL2. One issue we've run into is the following error (I'm using autobuild b266):

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: not implemented
at javax.media.opengl.glu.GLU.gluScaleImage(GLU.java:1479)

Is there something in particular in the profile/capabilities initialization which must be done to enable gluScaleImage? Should I add an enhancement request to bugzilla?

Thanks.

If you reply to this email, your message will be added to the discussion below:
http://jogamp.762907.n3.nabble.com/method-not-implemented-gluScaleImage-tp2304656p2304656.html

To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

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

OwenD

Re: method not implemented: gluScaleImage

Thanks for the reply. Switching to GLUgl2 fixes the "method not implemented" error. However, we are seeing a new issue with gluScaleImage when the image is relatively large:

Exception in thread "main" java.lang.OutOfMemoryError
      at sun.misc.Unsafe.allocateMemory(Native Method)
      at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:102)
      at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
      at com.jogamp.opengl.impl.glu.mipmap.Type_Widget.<init>(Type_Widget.java:59)
      at com.jogamp.opengl.impl.glu.mipmap.Image.empty_image(Image.java:522)
      at com.jogamp.opengl.impl.glu.mipmap.Mipmap.gluScaleImage(Mipmap.java:588)
      at javax.media.opengl.glu.gl2.GLUgl2.gluScaleImageJava(GLUgl2.java:375)
      at javax.media.opengl.glu.gl2.GLUgl2.gluScaleImage(GLUgl2.java:510)

when called like this:

public void testGluScaleImage()
{                
    int widthin = 559;
    int heightin = 425;
    
    int widthout = 1024;
    int heightout = 512;
    
    int textureInLength = widthin * heightin * 4;
    int textureOutLength = widthout * heightout * 4;
    
    byte[] datain = new byte[textureInLength];
    byte[] dataout = new byte[textureOutLength];
    
    ByteBuffer bufferIn  = ByteBuffer.wrap(datain);
    ByteBuffer bufferOut = ByteBuffer.wrap(dataout);        
    _glu.gluScaleImage(GL.GL_RGBA, widthin, heightin, GL.GL_UNSIGNED_BYTE, bufferIn, widthout, heightout, GL.GL_UNSIGNED_BYTE, bufferOut);
}

gouessej

Re: method not implemented: gluScaleImage

Administrator

Please use this as VM argument:
-XX:PermSize=256m

Your operation requires more native memory than the default perm size.

Julien Gouesse | Personal blog | Website

OwenD

Re: method not implemented: gluScaleImage

Adding that option changes the error message to "An unrecoverable stack overflow has occurred."

Using JOGL2, the gluScaleImage call takes around 1 minute of CPU time and consumes all available memory on the system (1-2GB) before crashing with one of the errors. The same call using JOGL1 completes almost instantly with no VM parameters needed.

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

Interesting. I get the same error when I try this (i.e. it uses all 8 GB on my machine, then starts paging while I frantically try to kill it).

But when I step through the insides of gluScaleImage() in the debugger, it completes without a problem (though Image.fill_image() and Image.empty_image() do take a few seconds each.

The source code seems pretty much identical between JOGL 1.1.1a and JOGL 2. Maybe you were using the C path in JOGL 1 somehow? You might try setting jogl.glu.nojava=true, which seems to bypass the Java scaling method in favor of a C method (which I can't see any source code for, so it may not work).

I'll look at the Java method some more to see what's going on there.

OwenD

Re: method not implemented: gluScaleImage

Adding -Djogl.glu.nojava=true yields:

Exception in thread "main" javax.media.opengl.GLException: Method "gluScaleImageC" not available
        at javax.media.opengl.glu.gl2.GLUgl2.gluScaleImageC(GLUgl2.java:116)
        at javax.media.opengl.glu.gl2.GLUgl2.gluScaleImage(GLUgl2.java:512)

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

I've confirmed that the code is almost identical between the JOGL1 and JOGL2 paths. I wrote unit tests for both JOGL1 and JOGL2, and confirmed that JOGL1 works fine on this. Next I'll step through both versions in parallel and look for different data values

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

In reply to this post by OwenD

Found it. Class Type_Widget that's used in Image allocates its buffer as "direct" in JOGL2, but it didn't in JOGL1.

public Type_Widget() {
buffer = ByteBuffer.allocate( 4 ); // JOGL 1
}

public Type_Widget() {
buffer = ByteBuffer.allocateDirect( 4 ); // JOGL 2
}

Apparently creating tons of these inside the tight loops of Image.fill_image() and Image.empty_image() chokes the JVM. That's why it works when you step through slowly in the debugger -- it gives the JVM a chance to catch up.

I'll create a bug report and a patch request for this. In the meantime, if you're building JOGL yourself you can make the above change in Type_Widget.java and it should let you proceed.

OwenD

Re: method not implemented: gluScaleImage

Thanks! I haven't been building JOGL myself but I'll give it a try (I'm anxiously awaiting bugs #450 and #461 to make it in too).

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

In reply to this post by OwenD

Bug report at https://jogamp.org/bugzilla/show_bug.cgi?id=463. You can CC yourself to be informed of its progress. I'll submit the patch tomorrow, hopefully we can get it in quick.

Thanks for reporting this!

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

In reply to this post by OwenD

Remind me of bug 461 if it's not fixed in the next release. Sven's been working on the capabilites choosing code (which it sounds like your bug may involve) so I don't want to dig too deep into that until I see what the next release looks like.

Michael Bien

Re: method not implemented: gluScaleImage

In reply to this post by Wade Walker

the problem here is prob. that the jvm is unable to allocate small
dbbs (direct byte buffers). It will usually give you a to around 4mb
rounded chunk and just claim that its smaller (at least it was the case
around 2 years ago as i checked the code). I have the same problem in
jocl and try to be very careful with buffer allocation internally
(static allocated sliced buffers, and in worst case threadlocal static
buffers). dbbs are allocated in the perm generation which is usually
only swept in full garbage collections.

when debugging this issues i recommend to use a recent JDK (6 or 7)
since it has usually better diagnostic messages in the OOM exceptions.
(jvisualvm is also quite cool for monitoring the permgen)

-michael

On 01/24/2011 11:47 PM, Wade Walker [via jogamp] wrote:

>
> Found it. Class Type_Widget that's used in Image allocates its buffer as
> "direct" in JOGL2, but it didn't in JOGL1.
>
> public Type_Widget() {
> buffer = ByteBuffer.allocate( 4 ); // JOGL 1
> }
>
> public Type_Widget() {
> buffer = ByteBuffer.allocateDirect( 4 ); // JOGL 2
> }
>
> Apparently creating tons of these inside the tight loops of
> Image.fill_image() and Image.empty_image() chokes the JVM. That's why it
> works when you step through slowly in the debugger -- it gives the JVM a
> chance to catch up.
>
> I'll create a bug report and a patch request for this. In the meantime, if
> you're building JOGL yourself you can make the above change in
> Type_Widget.java and it should let you proceed.
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://jogamp.762907.n3.nabble.com/method-not-implemented-gluScaleImage-tp2304656p2324170.html
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

Aha, that sounds like the last piece of the puzzle. I couldn't figure out why just a few million 4-byte direct NIO buffers was killing the JVM. If it's a few million 4MB buffers, that explains it

gouessej

Re: method not implemented: gluScaleImage

Administrator

In reply to this post by Michael Bien

I agree with Mickael. Maybe using a single direct NIO buffer whose size is the same than a memory page and using slicing on it would solve the problem. Slicing is already used in JOGL in Project.java.

Julien Gouesse | Personal blog | Website

Wade Walker

Re: method not implemented: gluScaleImage

Administrator

In reply to this post by OwenD

Submitted this fix and a unit test at https://github.com/sgothel/jogl/pull/20.

Julien, I totally agree that allocating one big direct buffer and slicing it would be faster. However, since we're trying to fix bugs to finalize the JOGL 2 release, I don't want to change any more code than the absolute minimum right now. We can submit an enhancement later if users say they could benefit from improved speed here

Sven Gothel

Re: method not implemented: gluScaleImage

Administrator

On Tuesday, January 25, 2011 17:04:47 Wade Walker [via jogamp] wrote:

>
> Submitted this fix and a unit test at
> https://github.com/sgothel/jogl/pull/20.
>
> Julien, I totally agree that allocating one big direct buffer and slicing it
> would be faster. However, since we're trying to fix bugs to finalize the
> JOGL 2 release, I don't want to change any more code than the absolute
> minimum right now. We can submit an enhancement later if users say they
> could benefit from improved speed here
>

There would be another tool useful in this regard,
nio lazy buffers (nlb).
nlb would
- instantiate NIO lazy when needed
- use common nio mem pool

this would enhance things a lot, as seen in a prev project.

~Sven

Michael Bien

Re: method not implemented: gluScaleImage

On 01/25/2011 05:16 PM, Sven Gothel [via jogamp] wrote:

>
> On Tuesday, January 25, 2011 17:04:47 Wade Walker [via jogamp] wrote:
>> Submitted this fix and a unit test at
>> https://github.com/sgothel/jogl/pull/20.
>>
>> Julien, I totally agree that allocating one big direct buffer and slicing it
>> would be faster. However, since we're trying to fix bugs to finalize the
>> JOGL 2 release, I don't want to change any more code than the absolute
>> minimum right now. We can submit an enhancement later if users say they
>> could benefit from improved speed here
>>
> There would be another tool useful in this regard,
> nio lazy buffers (nlb).
> nlb would
> - instantiate NIO lazy when needed
> - use common nio mem pool

prob with pools: multithreading, fragmentation (esp both in combination)

-> makes it very hard to do it "right"

but... yes we have to go this path earlier or later. Maybe even decide
case-to case instead of a generic pooling api how we want to solve that.
E.g as already mentioned in jocl i have different kind of static
allocated / lazy allocated memory. For instance threadlocal for per
thread command queues and lazy + synchronized for not performance
critical code (e.g cachable hw information queries).

... continuing with my boring exam preparations.. :(

-michael

> this would enhance things a lot, as seen in a prev project.
>
> ~Sven
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://jogamp.762907.n3.nabble.com/method-not-implemented-gluScaleImage-tp2304656p2331438.html
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/