Question about classpath arguments causing conflicts

[xicon]

Hi

I have been experimenting with JOGL and classpath arguments after i noticed that JOGL was using Generic Microsoft Drivers on my system.

I have noticed the classpath argument causing the effect is -Xmx, if i set the allocated heap to anything more than 750m, i.e. at 755m the drivers used by JOGL default to the Generic Microsoft Drivers with only support for OpenGL 1.1.0.

I know that I shoudn’t really set it too high unless its on a machine with a lot of memory (am using 512m) but was wondering whether this is an issue with JOGL? or just that by me setting the maximum heap size high relative to my pc’s memory it is causing conflicts on my system?

Any information to shed light on this would be greatfully recieved

Thanks
Mike

[kbr]

What kind of graphics card / drivers do you have?

I suspect that making the heap that large is preventing your card’s drivers from either loading at their required / preferred base address in memory or that they couldn’t memory map in something like the control registers for the card.

[GKW]

I remember reading about this on a forum somewhere with nVidia drivers. I have no idea if they ever fixed it. nVidia and ATI just released new drivers yesterday so download one of those if you can.

[GKW]

This is a message from Mark Kilgard at nVidia 08-26-2003:

The initialization of the OpenGL driver does require a fair amount of virtual address space. In general (without a 64-bit OS), applications are limited to somewhere between 3 and 2 gigabytes of virtual address space (depending on your OS).

Libraries such as OpenGL take up a fair amount of virtual address space because mappings must be established for OpenGL’s data structures, mappings to AGP memory, and mappings to video memory.

I suspect you went from a 64MB or 128MB GeForce Ti 4600 card to a 128MB or 256MB GeForce FX card. The mapping necessary for this extra memory along with a larger data structure footprint to handle the extra OpenGL functionality provided by the GeForce FX likely account for your failure to initialize the OpenGL driver.

When NVIDIA’s OpenGL driver fails to initialize, your application falls back to Microsoft’s slow software-only OpenGL driver under Windows (as you have found out).

NVIDIA is aware of that currently the virtual memory consumption by the driver is too great when GeForce cards with big memorys are combined with graphics applications demanding most of the available virtual address space. We are working to reduce the driver’s virtual memory footprint to alleviate the problem you are experiencing.

Keep in mind that the OpenGL library isn’t the only culprit usually. There are often other DLLs that may be consuming large chunks of your virtual address space.

Until NVIDIA can release a driver that reduces OpenGL’s virtual memory footprint, the best advice is to intialize OpenGL early (creating your OpenGL context, with GLUT that means calling glutInit), minimizing the size of your application’s own memory arrays, and checking if other DLLs are consuming an inordinate share of your virtual address space.

I hope this helps.

• Mark

[xicon]

The graphics card is an onboard Intel graphics card with the latest drivers (i think) but since its a pretty naff I am not surprised it doesn’t work.

Thanks very much for clarifying the problem
Mike