Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (686)
Games in Android Showcase (198)
games submitted by our members
Games in WIP (758)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java heap conflict forces Intel drivers to fail  (Read 2087 times)
0 Members and 1 Guest are viewing this topic.
Offline ahelsing

Junior Newbie

« Posted 2007-04-12 16:02:46 »

Let others be forewarned:

My customer was complaining that they always got the Microsoft GDI (software-only) OpenGL driver when running my Jogl application.

After much investigation, I've found that in some circumstances, the Java heap conflicts with where the Intel OpenGL Device Driver for the various Intel chipsets (eg 82865G) wants to load (either to put itself, or to store its internal stuff).

By removing the -Xmx argument (or lowering the specified max heap size) they get the Intel driver to load and run.

My application is a stand-alone application (neither an applet nor a WebStart app), using Jogl 1.1.0-rc3, jdk1.4.2 or 1.5.0.

I believe this is related to the issue previously mentioned as only an applet/IE issue:

My theory is that since the Intel chips store all their info in memory, they may have particular address spaces they want to use (or some particular alignment), and just bail out if they cant get it.

Has anyone else run into this issue?

Is this something that Java could avoid some day?

Attached find the trivial Jogl app I used to test this.  Note that this app is also a generic "print out basic system info
and Jogl / OpenGL capabilities" application, useful for debugging client installs.
Offline Ken Russell

JGO Coder

Java games rock!

« Reply #1 - Posted 2007-04-12 16:17:06 »

Sorry for the trouble.

You should complain to Intel about this. I have never heard of another graphics vendor's drivers failing to enable hardware acceleration due to an address space conflict. The JVM lets the base OS decide where to put the Java heap. Even if we had chunked (non-contiguous) Java heaps in the JVM there wouldn't be a guarantee that one of those chunks wouldn't be poorly placed so as to conflict with the address space region the Intel graphics drivers want.

This is an especially serious problem if this is happening with standalone Java processes. This issue has been recently raised in the context of running Java and JOGL applets in Internet Explorer, which is something of a special case which we can work around, but if it's happening with normal Java applications then Intel needs to fix their broken drivers.
Offline ahelsing

Junior Newbie

« Reply #2 - Posted 2007-04-12 16:59:49 »

I have submitted a query to Intel, though I'm not holding my breath.

I suspected it was a driver problem -- one of many that these drivers seem to have.

Does anyone know of tools to let me see what address space the driver wants? And what space the JVM is using? Maybe a tool to force Java to load into spaces outside of the area that the driver wants?

I doubt I'll go down that path though (what a pain), since for most purposes I can just restrict my heap size to something much smaller, and less likely to conflict.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder

Java games rock!

« Reply #3 - Posted 2007-04-13 07:23:42 »

Does anyone know of tools to let me see what address space the driver wants? And what space the JVM is using?

The jmap tool that comes with the JDK is capable of showing you this information, but it looks like the version that ships on Windows is unnecessarily restricted and doesn't print it. There are tools for example from SysInternals like ProcessExplorer that will show you low-level information about address space mappings, but there's no easy correlation to show you for example what portion is the Java heap.

Maybe a tool to force Java to load into spaces outside of the area that the driver wants?

I think this is unlikely.

The only way I can potentially think of to work around this issue would be to write your own Java launcher, manually reserve exactly the address space region the driver wants, start the JVM and let it allocate its heap elsewhere in the address space, and then unreserve the region and start the JOGL portion of the app which will hopefully cause the driver to load into the right place. This is highly unlikely to work.

If Intel isn't responsive then if I were you I'd vote with my dollars the next time and get a machine with NVidia graphics, since their OpenGL driver support is generally the best, and encourage people via word-of-mouth to do the same.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

roseslayer (478 views)
2016-08-06 11:43:29

roseslayer (434 views)
2016-08-06 09:43:11

xTheGamerCodes (511 views)
2016-08-04 15:40:59

xTheGamerCodes (504 views)
2016-08-04 15:40:24

orrenravid (852 views)
2016-07-16 03:57:23

theagentd (929 views)
2016-07-11 14:28:54

Hydroque (1025 views)
2016-07-06 05:56:57

Hydroque (1018 views)
2016-07-03 08:52:54

GrandCastle (833 views)
2016-07-01 09:13:47

GrandCastle (640 views)
2016-07-01 09:09:45
Rendering resources
by Roquen
2016-08-08 05:55:21

Rendering resources
by Roquen
2016-08-08 05:52:42

Rendering resources
by Roquen
2016-08-08 05:50:38

Rendering resources
by Roquen
2016-08-08 05:49:53

Rendering resources
by Roquen
2016-08-08 05:32:39

Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!