New D3D pipeline in mustang build 33

Java 2D
#1

As some of you have noticed, we’ve integrated a new D3D pipeline into mustang build 33. I’ll probably write something similar to Chris did for the Opengl pipeline (may be not as extensive, since the pipelines are pretty similar). Chris’ article for your references:
http://today.java.net/cs/user/print/a/147

In the meantime, I’ll just say a few words so you can start checking it out if you want to.

The bug id for the pipeline is
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5104393
An important performance improvement to the pipeline, which is also in b33:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6252147

Currently the d3d pipeline does most of what the opengl pipeline is capable of, with the exception of:

  • gradient paint (yeah, sorry)
  • xor rendering mode (still accelerated via gdi where possible)
  • accelerated copies from a system memory surface to an accelerated
    surface (see Chris’ article for more info) - mostly relevant for the first
    copy from BufferedImage to volatileImage, then the image is cached in
    a texture anyway
  • the VolatileImage => VolatileImage or VolatileImage => Screen
    copies are still done via ddraw Blit. This also means that
    compositing/transformation for VI->VI aren’t accelerated and go
    through our software loops - hopefully not many people use VIs for
    sprites
  • rendering to the screen is not accelerated, only to a VolatileImage or
    BufferStrategy’s backbuffer (a Direct3D restriction)

One minor difference between ogl and d3d pipelines is that the d3d pipeline always uses the Direct3D transformation engine for geometry transformations (with thin stroke), even for shapes (the opengl pipeline does the rasterisation using our software rasterizer and then feeds the resulting spans to opengl).

Note The pipeline is disabled by default, since we’re still working on some quality and robustness issues. We have all intentions of enabling it by default or mustang.

To enable it, provide the -Dsun.java2d.d3d=true flag.
Unfortunately, I didn’t have time to add any output when the pipeline is enabled, but you can use -Dsun.java2d.trace=log to make sure it is.

It’s also enabled if the good old -Dsun.java2d.translaccel flag is set (I’m assuming if you’re crazy enough to use this flag, you’ll be fine with the new pipeline =)

Note that there are cases when the pipeline won’t be enabled even with the d3d=true set, that is, if we detect that there’s not enough capabilities provided by the d3d device.

Also, our implementation tends to highlight the quality issues with the video drivers, so don’t be surprised if you see some rendering artifacts. (most of them are indeed drivers issues because they disappear once a reference Mircosoft d3d rasterizer is selected)

Some known issues with the b33 version of the pipeline:
some of the fullscreen functionality may be broken, like alt+tabbing in/out of the app, restoration of the surfaces when a command line console goes fullscreen. Bugs:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6255408
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6255346
These should be fixed in the next build.

Please try the new pipeline, and let us know what you think.
When reporting problems, please provide as much information about the os, hardware and drivers as posssible, it really helps.

Thanks,
Dmitri
Java2D Team

#2

VM crash while running my game:

23-Apr-2005 5:04:12 PM mightybubbles.MightyBubbles
SEVERE: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.windows.Win32OffScreenSurfaceData
java.lang.ClassCastException: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.windows.Win32OffScreenSurfaceData
at sun.java2d.windows.WinBackBuffer.getHWSurfaceData(WinBackBuffer.java:36)
at sun.awt.Win32GraphicsConfig.flip(Win32GraphicsConfig.java:431)
at sun.awt.windows.WComponentPeer.flip(WComponentPeer.java:768)
at java.awt.Component$FlipBufferStrategy.flip(Component.java:3461)
at java.awt.Component$FlipBufferStrategy.show(Component.java:3564)
at game2d.TickAnimator.run(TickAnimator.java:109)
at game2d.AbstractAnimator.start(AbstractAnimator.java:122)
at mightybubbles.MightyBubbles.(MightyBubbles.java:260)
at mightybubbles.MightyBubbles.main(MightyBubbles.java:720)

Demo scale time: 1114290251967

An unexpected error has been detected by HotSpot Virtual Machine:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x03d20b81, pid=3604, tid=3992

Java VM: Java HotSpot™ Client VM (1.6.0-ea-b33 mixed mode, sharing)

Problematic frame:

C 0x03d20b81

An error report file with more information is saved as hs_err_pid3604.log

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

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

The bug happened during an image scale transform.

The game was running in 640x480x32 at 85h

system specs:

  • nVidia GeForce2 MX 200 32 megs
  • DirectX9.0c
  • video driver version: 71.84
  • WinXP SP2
  • AMD Athlon 1.4GHz

VM parameters:
Xms32m
sun.java2d.accthreshold=0
sun.java2d.d3d=true

#3

I detected a performance problem with build 33. I’ve developed a level viewer that scrolls background and foreground images. The background contains only a big image (1200x900x32) that scrolls slowly and the foreground contains tile images.

I run the program in 800x600x16 at 150 hertz. With Java 1.5.0_02, the program runs at 150 fps and more but with Mustang b33, it runs at maximum 20 fps. My guest is that with Mustang, no image acceleration occurs. Why? You said that the pipeline won’t be enabled when it doesn’t detect enough capabilities with the d3d device:
“Note that there are cases when the pipeline won’t be enabled even with the d3d=true set, that is, if we detect that there’s not enough capabilities provided by the d3d device.”

The problem might be related to that logic?

Here my system specs:

  • nVidia GeForce2 MX 200 32 megs
  • DirectX9.0c
  • video driver version: 71.84
  • WinXP SP2
  • AMD Athlon 1.4GHz

VM parameters:
Xms32m
sun.java2d.accthreshold=0
sun.java2d.d3d=true

#4

Thanks for trying out the new pipeline.

The ClassCastException is a known bug (don’t have the id handy), unrelated to the d3d pipeline, but the crash isn’t.
Did it crash during startup? Or did you alt+tab out of the app when it was fullscreen?

Could you please post (or semd me) the vm crash log file?

Regarding performance issues. First, to make sure the pipeline is enabled, run your app with -Dsun.java2d.trace=count, and when the app exits, see if there are any primitives with names starting with D3D.

There are appear to be performance issues with scrolling (which is implemented as DDraw blit) on Nvidia MX boards, may be you’ve run into it.

I’ll run your game on MX and other boards and see if I can reproduce these issues.

Thanks,
Dmitri
Java2D Team

#5

[quote] Did it crash during startup? Or did you alt+tab out of the app when it was fullscreen?
[/quote]
The ClassCastException appeared and the VM crashed less than 1 second later but not immediatly. The crash seems to be more or less related to the exception.

For the VM log, I’ll provide it you when I’ll be home since I don’t have it with me.

I would be surprised that the performance problem is related to my video card since my code doesn’t scroll images actually. It gives the impression of doing that but the algorithm I use is as following:

  • for the background content, I draw the portion of the big image according to location of the clipping area (the entire screen in this case) relative to the big image. In other words, it’s like having a window that you slide on every direction on a wall and you can see only a portion of the wall via the window.
  • for the foreground content, I fill the screen of tiles that are of size 64x64. The tiles are stored in a big array as a placeholder for the entire level.

In other words, I don’t use scrolling operations that could be provided by AWT or Swing.

And concerning my game, I don’t think it will be useful for you because Java Webstart prevents setting successfully any sun.java2d properties so eventhough I declare sun.java2d.d3d=true in my .jnlp file, AWT will ignore it completly due to an obscure known problem with webstart and AWT.

#6

OK, I see it now. It’s possible that your image isn’t being acceelrated (with d3d) because it’s larger than allowed texture size for your boards.

Although in that case it should still be accelerated as a direct draw surface…

But in any case, having such a large image is asking for troubles =)
Could you try to break it up into smaller images (preferably square, and power of two size)? Most boards don’t like textures larger than 512x512.

Thanks,
Dmitri

#7

OK, that should explain the performance problem. How can I send you the VM log?

#8

Could you please send it to Dmitri.Trembovetski at sun dot com…

Dmitri

#9

Hi,

this time I wasn’t able to reproduce the VM crash and I had only bad results. Still the same system specs:

  • nVidia GeForce2 MX 200 32 megs
  • DirectX9.0c
  • video driver version: 71.84
  • WinXP SP2
  • AMD Athlon 1.4GHz

I ran my game and I had the know ClassCastException.

My second test was another program that scrolls background and foreground layers made up of tiles. On each frame, the entire screen is filled with tile images of size 64x64 for both background and foreground layers.

  • The resolution used: 800x600x16 at 144hertz
  • VM params: -ea -Djava.library.path=lib -Xms32m -Dsun.java2d.accthreshold=0 -Dsun.java2d.d3d=true
  • fps: fullscreen mode: ~12, window mode: ~35 (weird isn’t?)
  • no hardware accelaration according to sun.java2d.trace=count:

7176 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, Ushort565Rgb)
83 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArgb)
2 calls to DXFillRect
83 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
83 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArgb)
7176 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "Short 565 RGB DirectDraw")
83 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
39 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(OpaqueColor, SrcNoEa, AnyShort)
14725 total calls to 8 different primitives

I also tried with the system prop sun.java2d.ddforcevram=true but it changed nothing.

And when I tried the program in 32 bits resolution (at 144h) I got the following exception:


sun.java2d.InvalidPipeException: Can't create offscreen surf
      at sun.java2d.windows.Win32OffScreenSurfaceData.initSurface(Native Method)
      at sun.java2d.windows.Win32OffScreenSurfaceData.<init>(Win32OffScreenSurfaceData.java:275)
      at sun.java2d.windows.Win32OffScreenSurfaceData.createData(Win32OffScreenSurfaceData.java:141)
      at sun.java2d.windows.WinCachingSurfaceManager.createAccelSurface(WinCachingSurfaceManager.java:222)
      at sun.awt.image.CachingSurfaceManager.initAcceleratedSurface(CachingSurfaceManager.java:276)
      at sun.java2d.windows.WinCachingSurfaceManager.initAcceleratedSurface(WinCachingSurfaceManager.java:236)
      at sun.java2d.windows.WinCachingSurfaceManager.<init>(WinCachingSurfaceManager.java:100)
      at sun.java2d.SurfaceManagerFactory.createCachingManager(SurfaceManagerFactory.java:43)
      at sun.awt.image.SurfaceManager.getManager(SurfaceManager.java:54)
      at sun.java2d.SurfaceData.getDestSurfaceData(SurfaceData.java:113)
      at sun.java2d.SunGraphicsEnvironment.createGraphics(SunGraphicsEnvironment.java:345)
      at java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1131)
      at java.awt.image.BufferedImage.getGraphics(BufferedImage.java:1119)
      at sun.awt.windows.WCustomCursor.createNativeCursor(WCustomCursor.java:35)
      at sun.awt.CustomCursor.<init>(CustomCursor.java:80)
      at sun.awt.windows.WCustomCursor.<init>(WCustomCursor.java:28)
      at sun.awt.windows.WToolkit.createCustomCursor(WToolkit.java:679)
      at graphics.GraphicsUtil.setMouseCursorVisible(GraphicsUtil.java:114)
      at tiled.test.SimpleViewer.initializeDisplay(SimpleViewer.java:77)
      at tiled.test.SimpleViewer.main(SimpleViewer.java:221)
#10

This is weird. The pipeline doesn’t get enabled for some reason.

Could you please export and send me the following registry entry:
HKEY_CURRENT_USER\Software\JavaSoft\Java2D\1.6.0

This is where we store the results of the device testing (per device per bit depth).

Thanks,
Dmitri

#11

Dmitri,

I don’t know if I could give you a key but I noticed that if I execute my scroll program with Java 1.5.0_02 with only the sun.java2d.accthreshold=0 system prop then the images are not accelerated. It seems that when I pass sun.java2d.ddforcevram=true, the accleration is enabled.

I don’t know if this could help troubleshooting problems found with Mustang?

I can’t give you the registry settings for the moment.

#12

OK, I think I’ve found the possible cause of your problems. It’s the 16-bit depth and the way we initialize the d3d device.

Please try switching to 32-bit mode…

Thanks,
Dmitri
Java2D Team

#13

Will that change in the future?

[quote]OK, I think I’ve found the possible cause of your problems. It’s the 16-bit depth and the way we initialize the d3d device.

Please try switching to 32-bit mode…

Thanks,
Dmitri
Java2D Team
[/quote]

#14

[quote]Will that change in the future?
[/quote]
Yes. This is just a bug.
Interestingly, so far I’ve only been able to reproduce it on low-end nvidia boards.

I’m guessing that it doesn’t like the format of the stencil buffer I’m using, and the creation of d3d device fails.

Thanks,
Dmitri
Java2D Team

#15

[quote]OK, I think I’ve found the possible cause of your problems. It’s the 16-bit depth and the way we initialize the d3d device.

Please try switching to 32-bit mode…

Thanks,
Dmitri
Java2D Team
[/quote]
Hi Dmitri,

sorry but I’ve ran my program again and this time with build 34 but I still got no image acceleration both in 16 and 32 bits. You’ll have to investigate more on why the pipeline doesn’t get enabled. Also, I ran DxDiag and the it indicated that D3D is working properly.

You can give me a debug build and I’ll try to give the tracing result or other interesting logs.

#16

FYI: there were no 2d changes in b34. Our next integration will be into build 39 (around end of May).

I’m working on this bug.

Thanks,
Dmitri