video memory fills JVM memory allocation pool?

I’m writing an application that visualizes 3d point-clouds (thousand or millions of points that together create an image). This program allows the user to view different concentrations of a point cloud. Basically, it doesn’t render all the points that are available. If I try to increase that concentration on some of the larger point-clouds, the memory pool fills up.

I’m just curious if making GL calls fills up the JVM memory pool eventhough it should be accessing video memory

Can you describe how you render the point clouds? Do you use display lists, do you use immediate mode (e.g. glVertex() per point in the cloud), or vertex arrays/buffers? When picking vertices out of the cloud, do you use indices to reference static geometry, or are you rebuilding each time?

When you say that the memory pool fills up, are you getting a OutOfMemory exception from java, or a GL_OUT_OF_MEMORY error from openGL. Are you running out of direct memory or memory in general. You could try increasing the max heap size of your jvm and see if that helps.

I feel a little silly. It may not be a memory problem at all. I was assuming so because I would watch the memory usage in the task-manager climb near maximum, then it would crash. I finally look at the real error message and it is complaining about something else:

[quote]#

An unexpected error has been detected by Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c91a214, pid=252, tid=3340

Java VM: Java HotSpot™ Client VM (10.0-b23 mixed mode windows-x86)

Problematic frame:

C [ntdll.dll+0x1a214]

An error report file with more information is saved as:

C:\Documents and Settings\Michael\My Documents\SLUGVIEW\hs_err_pid252.log

If you would like to submit a bug report, please visit:

http://java.sun.com/webapps/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

[/quote]
Here is my post before looking at the error message…

The code below is what creates the display list to build the cloud in GL. The downsampling variable controls the concentration of points. The colorForPoint function basically creates a rainbow of colors. Eventually the program will use real-world colors, but not right now. I’m not certain about your second question. To get to the points I project window coordinates using glu.project/unproject, and combine it with the viewport matrix (i.e. To get the exact point on the screen:

This gets the depth component Note: proj.getViewport returns the viewport matrix from GL;

gl.glReadPixels(winX ,proj.getViewport()[3]-winY , 1,1, GL.GL_DEPTH_COMPONENT, GL.GL_FLOAT, zDepth);


This gets the point;

glu.gluUnProject(winX, winY, zDepth, mdlMatrix, 0, prjMatrix, 0, viewportMatrix, 0, coords, 0);
protected void buildDisplayList(int downsampling, ProgressMonitor updt){
        if (dispList > 0) gl.glDeleteLists(dispList, 1);
        dispList = gl. glGenLists(1);
        if (dispList <= 0) throw new Error("Could not appropriate display list");
        gl.glNewList(dispList, GL.GL_COMPILE);
        gl.glBegin(GL.GL_POINTS);
        for (int i = 0; i < points; i += downsampling+1){
            double[] clr = colorForPoint(i);
            gl.glColor4d(clr[0], clr[1], clr[2], ALPHA_BRIGHTNESS);
            gl.glVertex3d(data.get(i, 0), data.get(i, 1), data.get(i, 2));
        }
        gl.glEnd();
        gl.glEndList();
    }

Also, I’ve have to use -Xmx with this program. It uses too much memory for the 64mb cap. So, I have been. That’s my problem. With Windows systems, I’ve gone as high as I can with -Xmx.

Thank you for your help, and sorry if I wasted your time

Now that I’ve made the proper search in the forums (for “ntdll”). I’m finding this error all over. I stopped using a display list and it works fine. Of course, I couldn’t possible not use a display list for performance reasons. Is this is a bug in my code, or a bug in jogl, or a bug in ATI drivers? I have 2 4870’s crossfired (I tried disabling crossfire, and it still happened. Even faster even)

It’s probably a bug in the opengl driver from ATI, but this is just a guess. You should anyway stay away from display lists for your kind of visualization and take a look at vertex arrays or vertex buffer objects. Basically you are using an array or a buffer to store the locations of your points (and other attributes like color for instance) and draw them with one gl call after telling open gl where to find the vertices/colors etc.

I’ve looked up Vertex arrays and it seems like that’s exactly what this program should have been built on (I didn’t write the original code). I think I’m going to convert over to them. Thanks for your help

Sorry, I was a little unclear, instead of picking, I should have said choosing since from your first post, it sounded like you had some dynamic point density that would adjust how the shape is rendered.

When you were using display lists, how often did you create a new one? If/when you made a new one, did you delete the previous one? These questions are just for my understanding, I agree with cylab about the use for vertex arrays/buffers. They should offer better performance, especially with dynamic geometry.