Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
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  
  New D3D pipeline in mustang build 33  (Read 4978 times)
0 Members and 1 Guest are viewing this topic.
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Posted 2005-04-22 21:41:39 »

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
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #1 - Posted 2005-04-23 19:10:18 »

VM crash while running my game:

23-Apr-2005 5:04:12 PM mightybubbles.MightyBubbles <init>
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.<init>(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(TM) 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

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #2 - Posted 2005-04-24 23:07:04 »

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #3 - Posted 2005-04-25 02:01:27 »

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

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #4 - Posted 2005-04-25 14:11:10 »

Quote
Did it crash during startup? Or did you alt+tab out of the app when it was fullscreen?
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.

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #5 - Posted 2005-04-25 19:07:17 »

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
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #6 - Posted 2005-04-25 22:21:35 »

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

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #7 - Posted 2005-04-26 02:52:55 »

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

Dmitri
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #8 - Posted 2005-04-26 22:27:33 »

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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
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)

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #9 - Posted 2005-04-27 04:00:46 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #10 - Posted 2005-04-27 18:09:22 »

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.

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #11 - Posted 2005-04-29 18:19:49 »

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
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #12 - Posted 2005-04-30 01:07:04 »

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


Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #13 - Posted 2005-04-30 03:12:00 »

Quote
Will that change in the future?


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
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #14 - Posted 2005-05-01 16:34:19 »

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

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.

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #15 - Posted 2005-05-01 18:42:58 »

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
Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (149 views)
2017-09-30 02:57:34

theagentd (214 views)
2017-09-26 18:23:31

cybrmynd (301 views)
2017-08-02 12:28:51

cybrmynd (288 views)
2017-08-02 12:19:43

cybrmynd (297 views)
2017-08-02 12:18:09

Sralse (291 views)
2017-07-25 17:13:48

Archive (968 views)
2017-04-27 17:45:51

buddyBro (1094 views)
2017-04-05 03:38:00

CopyableCougar4 (1670 views)
2017-03-24 15:39:42

theagentd (1430 views)
2017-03-24 15:32:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org 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‑gaming.org
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!