Not for tiger.
I can still reproduce this on my ATI Radeon 9500 Pro with Catalyst WinXP 5.1
drivers installed. The crash seems to be originating from the VM thread as
it is shutting down, so perhaps the crash happens as the driver DLLs are being
unloaded when the process exits. The problem is reproducible on Tiger,
Mustang, and in my single-threaded rendering workspace as well. I'll have
send this to ATI for further review.
###@###.### 2005-1-22 00:30:56 GMT
I've submitted a bug report to ATI (Ticket# 737-767959) regarding
this issue. I'm not aware of anything that can be done in the JDK
to workaround this problem. The crash only happens upon exit, so
it should be harmless (other than the fact that a nasty error message
is printed to the console). Note that as of Mustang-b27, the
OGL pipeline is much more stable due to the single-threaded rendering
changes (see 6219284), so if you've had trouble in the past with
the OGL pipeline on ATI boards, things should be getting better soon.
###@###.### 2005-03-09 23:30:36 GMT
Still no fix for this issue from ATI, despite repeated attempts to have them
investigate it. Fortunately, it appears that this problem is caused by a bug
in their pbuffer code, so if you enable our codepath that uses FBOs instead
of pbuffers, then this bug is no longer reproducible. In fact, using the FBO
codepath is much more reliable overall on ATI's drivers, which is why we are
planning to make the FBO codepath the default in Mustang (see 6439320 for more
See workaround section for what you can do in the meantime...
Well, still no driver fix from ATI. However, I have discovered that the
driver bug is not completely specific to the use of pbuffers, but rather is
caused by an interaction with the WGL_ARB_render_texture extension.
First, a history lesson. When the OGL-based Java 2D pipeline was first
developed in 2001/02, there were two WGL extensions proposed that went
hand-in-hand with WGL_ARB_pbuffer:
Both were designed as a way to copy a pbuffer to another OpenGL destination.
The former had a somewhat complicated spec (kind of an early precursor to
the GL_EXT_framebuffer_object extension), but it allowed developers to use
a pbuffer as a destination or as a texture object source. This meant it
was possible to render into a pbuffer, and then transform it just like any
other texture. The latter had a much simpler spec (almost identical to the
way things are done in GLX 1.3), but it didn't have all the render-to-texture
business, so it was fast for simple pbuffer->screen copies, but not great
for transforming/scaling (just like on the GLX side of things).
To make matters worse, at the time Nvidia supported one but not the other,
while ATI supported the other but not the one (can't remember the specifics).
Anyway, when it came time to port our OGL pipeline to Windows, the only
extension at that time to be supported by both Nvidia and ATI was
WGL_ARB_render_texture. I would liked to have gone with the much simpler
WGL_ARB_make_current_read extension, since it was so similar to what I
dealt with on the GLX side of things, but to support as many modern boards
as possible, I had to go with WGL_ARB_render_texture. It was a pain to
work through the driver issues with that spec (some of which remain today,
e.g. the issue in this bug report), but it worked reasonably well.
A few years have passed, and the landscape has changed a bit. Both ATI and
Nvidia now support both the WGL_ARB_render_texture and
WGL_ARB_make_current_read extensions. Unfortunately, Intel still does not
support WGL_ARB_render_texture, which means that our OGL pipeline has not
been available to approximately 50% of the market. There are other smaller
players (SiS, S3, XGI) that do support WGL_ARB_render_texture, but not
WGL_ARB_make_current_read, but even so, I've never had any luck getting our
OGL pipeline working on those boards; the drivers are simply too buggy.
The Delphi3D hardware registry has a good survey of which boards support each
In JDK 6 we added support for the GL_EXT_framebuffer_object extension. We
made that the default codepath (where supported), and we would like to make
that our preferred approach going forward (as the rest of the industry is
doing); it's fast, reliable, and cross-platform. But the fact of the matter
is that we still want to support as many older boards as possible that
do not support GL_EXT_framebuffer_object:
- Nvidia boards earlier than the GeForce FX 5xxx series
- ATI boards earlier than the Radeon 95xx series
- All Intel chips
Anyway, getting back to the bug at hand... In an effort to add support for
Intel boards, I added a codepath that uses the WGL_ARB_make_current_read
extension in place of the existing WGL_ARB_render_texture codepath. This
got us mostly working on Intel GPUs (modulo a few Intel driver bugs that
need to be worked out). But perhaps more interesting is that this ATI
crash-on-exit bug is no longer reproducible with the WGL_ARB_make_current_read
codepath, which suggests that the problem was not with pbuffers as originally
hypothesized, but rather with their interaction with the
WGL_ARB_render_texture extension. So this is actually a win-win situation.
I also tried this codepath on an Nvidia GeForce FX 5600 and found (using
SwingMark) that performance of WGL_ARB_make_current_read was a fair amount
better than with the existing WGL_ARB_render_texture codepath. On a couple
ATI Radeon boards, performance was just slightly better with
So it seems that there are lots of obvious wins with using the
WGL_ARB_make_current_read extension, but the question becomes: should we
do a one-for-one replacement, or should we try to support both extensions
going forward? While it is possible to support both extensions, the code
becomes even more complicated (it was bad enough already with
WGL_ARB_render_texture and GL_EXT_framebuffer_object). Also, we try as
much as possible to avoid adding new system properties, and we'd probably
have to add a new flag if we were to support both, which is less than ideal.
In my opinion, it would be much cleaner if instead we ripped out the old
WGL_ARB_render_texture code and replaced it with WGL_ARB_make_current_read.
This is something we could even backport to a JDK 6 update release, since
it should have minimal impact. The downsides of this approach are fairly
minimal. It means that there's no hope for getting the OGL pipeline working
on SiS boards (for example), until such a time comes that they support either
GL_EXT_framebuffer_object or WGL_ARB_make_current_read; but from what I've seen
there are too many other problems with SiS drivers to make me concerned about
this. Also, it means that developers using older (pre-FBO) boards may see
lower performance when trying to do bilinear scaling/transforming of
VolatileImages. Performance of this case was already not much better with
WGL_ARB_render_texture, so now all we would be doing is making performance
of this case on Windows much more similar to what is seen on Linux/Solaris.
Overall it should be a much more consistent experience when running apps on
For all of the above reasons, I'm planning to fully replace our
WGL_ARB_render_texture codepath with a simpler one based on
WGL_ARB_make_current_read. This means:
- no extra system properties
- much more straightforward code
- no more crash-on-exit on pre-FBO ATI boards (solves the bug at hand)
- preliminary support for Intel GPUs (additional changes
may be needed in a follow-on bug fix, TBD)