Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (113)
games submitted by our members
Games in WIP (562)
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  
  current state of 2D acceleration  (Read 4850 times)
0 Members and 1 Guest are viewing this topic.
Offline dbichko

Junior Newbie





« Posted 2007-02-17 02:48:00 »

Sorry if this is overly vague (and probably gets asked a lot), but I've been reading around this for the last couple of hours, and am thoroughly confused.

Basically, my question is: what's the relative performance of the D3D and OpenGL pipelines?  I've been reading Chris and Chet's  blogs, and it seem that vast improvements have been made to the OpenGL pipeline in the last couple of years, but is that just catching up to what D3D has already been doing?  It's hard to get a head-to-head comparison.

What I'm doing is extremely simple in its graphical requirements: it's a data visualization application that just needs to draw a bunch of tiny (a couple of pixels) colored segments; the problem is that it needs to draw hundreds of thousands of them in real time.

I also understand that there are serious stability issues with OpenGL drivers - has it at least gotten to the point where it's worth giving it a shot?

Any advice is appreciated.
Offline CommanderKeith
« Reply #1 - Posted 2007-02-17 03:22:51 »

I'm not a definitive expert on this either but let me try to share what I've learned.  Others like LinuxHippy (and ofcourse the Java2D team) know lots about this stuff.

By default Java2D uses Directx and direct3D in combination with 'software' rendering on windows XP and older windows versions.  There are additional VM flags you can use to get more out of D3D and DirectX like:

<property name="sun.java2d.ddforcevram" value="true" />
<property name="sun.java2d.translaccel" value="true" />
<property name="sun.java2d.ddscale" value="true" />

These are turned off by default since some drivers play up with them.  By turning these on I suppose we're using the 'D3D pipeline'.

The ogl pipeline is more advanced than the D3D one mainly because it does more fancy things like transparency, scaling, rotations etc which the D3D pipeline just won't do (it does it in software which is usually slower).  Also, the OGL pipeline uses a fast threading architecture called STR which is in Chris Campbell's blog.

A big problem coming up is that the D3D-software mixing which has worked OK to date just won't work in Windows Vista.  Everything has to be done in software or D3D.  Chet talked about it in his blog and currently java 6 just uses software. Hopefully the Java2D team will make a full-on 100% awesome D3D pipeline for a future version of Java whioch doesn't use software rendering at all.

About the OGL stability issue.  To me it seems as though no drivers which come with the computer/graphics card/operating system work with OGL at all  Sad.  You have to download a new one from the net.

That's why I'd recommend staying with Java2D to do your graphics since then you can give the user the option of using OGL, D3D, or software by just supplying different VM arguments.  Software rendering by the way is actually very quick on fast-CPU computers, nearly as fast as OGL.

Let us know how things work out!
Keith


Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #2 - Posted 2007-02-17 14:34:54 »

Well there is also a "native" D3D pipeline which uses D3D exclusivly (as far as I know) but lacks some features of the OpenGL pipeline.
So OpenGL is currently the most advanced Java2D backend *if* it works Wink

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

Innocent Bystander





« Reply #3 - Posted 2007-02-17 22:15:58 »

I also have a question about this issue. You say, software rendering is almost as fast as opengl on fast computers, but I have a simple test application, that renders randomly antialiased lines on the screen. My problem now is, that normal (D3D) or with opengl pipeline enabled I can draw about 10.000 lines per second. But directly with jogl I can draw 500.000 lines! So why can this be?
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #4 - Posted 2007-02-17 22:35:44 »

I also have a question about this issue. You say, software rendering is almost as fast as opengl on fast computers, but I have a simple test application, that renders randomly antialiased lines on the screen. My problem now is, that normal (D3D) or with opengl pipeline enabled I can draw about 10.000 lines per second. But directly with jogl I can draw 500.000 lines! So why can this be?

I guess this is because the way Java2D handles Antialiasing. To ensure correctness Java2D does not rely on OpenGLs antialiasing  and does some kind of combined hardware/software rendering. However I also could be wrong.
However OpenGL should clearly outperform the default pipeline because no VRAM readbacks are needed.

lg Clemens
Offline Eliwood

Junior Member




Stencyl


« Reply #5 - Posted 2007-02-17 22:44:07 »

Perhaps I was doing something wrong, but when I enabled the OGL pipeline for my game, for people with ATI cards or older cards, there was a lot of artifacting going on (black rectangles over sprites or random lines). It all ran just as well as the LWJGL variant, but the graphical artifacts ruined it.

Offline CommanderKeith
« Reply #6 - Posted 2007-02-18 02:15:28 »

Well there is also a "native" D3D pipeline which uses D3D exclusivly (as far as I know) but lacks some features of the OpenGL pipeline.
So OpenGL is currently the most advanced Java2D backend *if* it works Wink

lg Clemens

Wow, sounds great.  I've never heard of this, what is the VM option to turn it on?

Perhaps I was doing something wrong, but when I enabled the OGL pipeline for my game, for people with ATI cards or older cards, there was a lot of artifacting going on (black rectangles over sprites or random lines). It all ran just as well as the LWJGL variant, but the graphical artifacts ruined it.

It could be the graphics card driver but it could also be the version of java that was running the OGL pipeline.  Java 6 is much more robust.  For example on 1.4 or 1.5 JVMs I often got colour inversion using the OGL pipeline but with 1.6 (java 6) this hasn't happened.


Offline Eliwood

Junior Member




Stencyl


« Reply #7 - Posted 2007-02-18 08:19:02 »

The users were all using Java 6, and one had a top of the line ATI card (X1900), but then again, bad drivers can foul anything up. Still, LWJGL remains the safest option.

Offline campbell

Junior Member




Java games rock!


« Reply #8 - Posted 2007-02-18 20:47:21 »

The users were all using Java 6, and one had a top of the line ATI card (X1900), but then again, bad drivers can foul anything up. Still, LWJGL remains the safest option.

Did you file a bug report at bugs.sun.com?  (Screenshots, exact driver version, etc would help.)  We can't fix problems that we don't know about.  You're correct that in most cases it's the drivers fault, but we can work with ATI/Nvidia/etc to correct the problem.

Chris
Offline dbichko

Junior Newbie





« Reply #9 - Posted 2007-02-19 06:50:05 »

Ok, I've run some benchmarks, lets see if they make sense.

Very simple test - fill a 1024 x 768 panel with line segments 3 pixels tall (so, 262,144 segments total).

All tests were on win2k with the latest java 1.6; I ran everything a few times and picked representative numbers.

I first ran this on my (fairly uncommon) Matrox Parhelia 650:

Default (trace: DXDrawLine)
time: 2344, segs/s: 111836

-Dsun.java2d.d3d=true (trace: D3DDrawLine)
time: 4625, segs/s: 56679

-Dsun.java2d.noddraw=true (trace: sun.java2d.loops.DrawLine::DrawLine(OpaqueColor, SrcNoEa, AnyInt))
time: 375, segs/s: 699050

-Dsun.java2d.opengl=true just ran in software.

So turning on D3D halves the speed from the original DX, and software is 12 times faster than D3D?  Of course this card isn't supposed to do much 3D acceleration.

I am also not very familiar with the windows 3D APIs: what exactly is the difference between D3D and DX? I thought they were part of the same thing?
While playing around with the start-up options from my IDE, I also managed to run it in a mode that traced as "sun.awt.windows.Win32BlitLoops::Blit("Integer RGB DirectDraw", SrcNoEa, "Integer RGB DirectDraw")" - so DD, DX, and D3D are all different? (this ran a tiny bit slower than the DX).


I then figured I should run this on something that's a) more common, b) has decent 3D performance, and c) is far from the top of the line : GeForce2MX 200.

Default (trace: DXDrawLine)
time: 4438, segs/s: 59068

-Dsun.java2d.d3d=true (trace: D3DDrawLine)
time: 734, segs/s: 357144

-Dsun.java2d.noddraw=true (trace: sun.java2d.loops.DrawLine::DrawLine(OpaqueColor, SrcNoEa, AnyInt))
time: 250, segs/s: 1048576

-Dsun.java2d.opengl=true (trace: OGLDrawLine )
time: 141, segs/s: 1859177

So here at least D3D is 6 times faster than DX, but software is still 3 times faster, and OpenGL blows everything else away.

Is this a fair test for what I'm trying to do?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2007-02-19 07:40:41 »

Thanks for doing all that!  Very useful to know.  Even though your 3-pixel lines were probably straight up and not angled, maybe turning off anti-aliasing will produce different results.

-Dsun.java2d.d3d=true (trace: OGLDrawLine )
time: 141, segs/s: 1859177

I assume you meant -Dsun.java2d.opengl instead of d3d.

By the way, I thought that -Dsun.java2d.d3d was turned on by default since in the docs (http://java.sun.com/javase/6/docs/technotes/guides/2d/flags.html) it says that you should turn it off if there's problems with the driver.  Since you got unique stats with that option I suppose that is THE d3d flag.  If this is the case then maybe the docs on this should be changed.

Cool stuff, it's about time we found out how all of the options actually work on windows  Cool.

Keith


Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #11 - Posted 2007-02-19 12:45:48 »

By the way drawing directly to screen destroys the opengl-backend's capability of Single-threaded-rendering.
So for comparison better draw to a VolatileImage and draw this one after the test has been finished.
Offline dbichko

Junior Newbie





« Reply #12 - Posted 2007-02-19 12:57:25 »

Giving it the ANTIALIAS_OFF rendering hint didn't seem to make  a difference.

You are right, it does seem that d3d should be on for win2k (I even glanced at the source for 1.6, seems to be on) - don't know why it's getting turned off.
Offline dbichko

Junior Newbie





« Reply #13 - Posted 2007-02-19 13:35:11 »

By the way drawing directly to screen destroys the opengl-backend's capability of Single-threaded-rendering.
So for comparison better draw to a VolatileImage and draw this one after the test has been finished.

Thanks for the tip - that made the opengl results another 15% faster.

This is a bit OT, but what's the correct way to use VolatileImage buffers?  Does it make sense to always allocate one just for the render and throw it away after copying to the screen?  Or is it expensive to allocate them?

Or should I render to the VI, copy to a regular image buffer before releasing it, and use that for double buffering? (so that a repaint never causes and unexpected, and expensive, render because the VI has been invalidated).

Thanks for the help.
Offline campbell

Junior Member




Java games rock!


« Reply #14 - Posted 2007-02-19 17:37:51 »

By the way drawing directly to screen destroys the opengl-backend's capability of Single-threaded-rendering.

?

This is not true.  Are you just making things up as you go along?  Smiley

Quote
So for comparison better draw to a VolatileImage and draw this one after the test has been finished.

This one I can agree with.  It's pretty rare that anyone renders directly to the screen these days, so better to do your benchmarking to an accelerated offscreen, like BufferStrategy or VolatileImage.  But then you always have to remember to call Toolkit.sync() at the end of your rendering loop, to ensure pixels are completely flushed to the destination.  These things are taken care of already for you if you use our standard microbenchmarking utility, J2DBench:
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html

Chris
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #15 - Posted 2007-02-19 18:16:02 »

This is not true.  Are you just making things up as you go along?  Smiley

Oha I normally write a disclaimer that it maybe simply wrong what I wrote - but it seems here I simply missed it.
I thought I've read about that in some blog some time ago ... strange.

Sorry  Cry

lg Clemens
Offline MrBlack

Innocent Bystander





« Reply #16 - Posted 2007-02-26 00:20:28 »

I hope this is still on topic but I have a relevant question: is the OpenGL accelerated backend supported on OS X ?

If not, any estimates ? Smiley

Thank you.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (15 views)
2014-09-12 09:08:26

Norakomi (45 views)
2014-09-10 13:57:51

TehJavaDev (57 views)
2014-09-10 06:39:09

Tekkerue (26 views)
2014-09-09 02:24:56

mitcheeb (49 views)
2014-09-08 06:06:29

BurntPizza (33 views)
2014-09-07 01:13:42

Longarmx (19 views)
2014-09-07 01:12:14

Longarmx (21 views)
2014-09-07 01:11:22

Longarmx (20 views)
2014-09-07 01:10:19

mitcheeb (30 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!