United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6255507 : OGL: use GL_EXT_framebuffer_object extension for improved performance

Details
Type:
Enhancement
Submit Date:
2005-04-14
Status:
Resolved
Updated Date:
2008-02-06
Project Name:
JDK
Resolved Date:
2005-09-06
Component:
client-libs
OS:
solaris_9
Sub-Component:
2d
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:

Related Reports
Relates:
Relates:

Sub Tasks

Description
The new GL_EXT_framebuffer_extension is essentially a platform-independent
replacement for pbuffer and render-to-texture functionality.  It allows
for true render-to-texture functionality without the large VRAM footprint
requirements of pbuffers.  For example, one can create a framebuffer object
(FBO) with only a 32-bit color buffer and attach a stencil buffer only when
it is needed.  So for apps that don't make use of complex clipping, we could
probably avoid creating a stencil buffer, which would cut down on VRAM usage.
Currently, we would need to create a pbuffer to get the same functionality,
but typically the windowing system will allocate buffers that Java 2D doesn't
need, such as a backbuffer, depth buffer, accum buffers, and so on.
(Pbuffers can sometimes require as much as 192 bits per pixel, so the savings
with FBOs are obvious.)

Even better, one can render to an FBO without switching contexts (calling
MakeCurrent() over and over can be costly).  Currently, context switching
overhead makes Swing rendering slower when OGL is enabled.  This is because
Swing will render a couple things into their backbuffer (a pbuffer), copy
the pbuffer to the screen, and repeat.  Each time we switch the context
from the pbuffer to the screen and back to the pbuffer, we incur significant
overhead.  This overhead can be avoided (or at least minimized) when using
the FBO extension.
###@###.### 2005-04-14 19:32:11 GMT

                                    

Comments
EVALUATION

FBO support is now in mainstream drivers from both Nvidia (as of 76.64 on
Linux and Solaris, 77.77 on Windows) and ATI (as of 5.7 on Windows).  We will
now use FBOs instead of pbuffers as the accelerated surface for VolatileImages,
but only if the following conditions are met:
  - the GL_EXT_framebuffer_object extension is present (obviously)
  - the new sun.java2d.opengl.fbobject system property is set to "true" (off
    by default)
  - we are able to create an FBO with the appropriate attachments

The reason this will be disabled by default (at least for the near future) is
that there are still some kinks in the drivers.  For example, both Nvidia and
ATI do not yet support stencil attachments for FBOs, which is why I've filed
6313838 (and plan to fix it very soon), so that we eliminate our dependency on
stencil buffers.  Also, on Nvidia drivers, copyArea() is very slow for FBO
destinations (very similar to the bug reported in 6298243), which results in
slow scrolling when FBO support is enabled.  It looks like Nvidia will be
addressing that issue in an upcoming driver release.  Once the above issues
are resolved, we can consider turning on FBO support by default.
                                     
2005-08-22
EVALUATION

Beta drivers that include support for the FBO extension are just now becoming
available (e.g. the 7590 beta drivers for Linux from Nvidia support it).
Nvidia claims that context switching performance is improved by 2x with FBO.
An initial experiment on my Nvidia GF FX 5600 shows a 14% improvement in
SwingMark scores when using FBOs instead of pbuffers.
###@###.### 2005-04-14 19:32:11 GMT
                                     
2005-04-14



Hardware and Software, Engineered to Work Together