OGL pipeline improvements

[TheAnalogKid]

That’s because the D3D pipeline rearchitecture hasn’t been integrated yet into Mustang. Those changes will produce better performance on Windows than even the OGL pipeline for things like transforms and compositing. And regardless of the performance numbers, the DirectX-based APIs are better supported in Windows drivers and by Microsoft going forward than OGL ever will be.

Chris

Chris,

could you list or explain in details what are the anticipated improvements with the rearchitectured D3D pipeline please? You talked about transforms. Which transform operations? What are the other improvements? Also do you know if these improvements risk to be integrated in release like 1.5.1 for example? I think I really need these performance improvements if I want to create fast special effects in my game using Java2D. I’d really like to continue with Java2D and not beign forced to switch to that ugly OpenGL programming model via LWJGL because of performance issues.

Thanks!

[campbell]

[quote]I reported another bug I came across about one month ago, but did not get any repsonse till now.
The ID is: 409145 - but its not visible till now.

The bug-report was that the size of volatile/managed images created via Component.createImage() is limited.
However I’ve found out some other facts which seem to show that this is an Java2D and not a driver bug:
[/quote]
Sorry that your bug report was waiting in our submission queue for a while. I just kicked it into our bug database, tracked under 6246760. I’ll look into it more closely this week but first a couple quick notes…

In an upcoming Mustang build (b32 maybe?) you will no longer run into this problem because createImage() will now always be returning a “normal” managed image for the OGL pipeline, instead of a wacky pbuffer-based variant. See 6240664 for more details.

Even so, VolatileImages will continue to be backed by pbuffers, so this problem may still be present. I’ll have to dig deeper to see what’s going on here.

Thanks again for reporting the issue.
Chris

[campbell]

Are there any plans for Mustang to implement a path for render-to-texture operations with EXT_framebuffer_object? By the time Mustang development finishes, I would expect implementations of this extension to be widely available. It would improve both performance and (video) memory consumption (especially on non-Windows platforms).

Hi Spasi,

We’ve been tracking this extension for quite some time, and I agree that it might be useful for us (probably in the Dolphin (7.0) timeframe, rather than for Mustang). It may only be implemented for newer hardware, in which case we’ll still have to maintain our existing pbuffer/render-to-texture implementations. When/If this extension is more widely supported, it would be great if we could replace our existing platform-specific code entirely, as this extension would make it easy to manage offscreen surfaces in shared code.

Thanks,
Chris

[campbell]

Chris,

could you list or explain in details what are the anticipated improvements with the rearchitectured D3D pipeline please? You talked about transforms. Which transform operations? What are the other improvements? Also do you know if these improvements risk to be integrated in release like 1.5.1 for example? I think I really need these performance improvements if I want to create fast special effects in my game using Java2D. I’d really like to continue with Java2D and not beign forced to switch to that ugly OpenGL programming model via LWJGL because of performance issues.

Thanks!

Hi there,

Dmitri will post more details about the D3D pipeline improvements sometime in the next couple weeks (we’re hoping). We’ll start a new thread for discussing this work, rather than take this OGL thread off-topic. Sorry to be vague, but rest assured that the improvements will be available soon in an upcoming Mustang build.

Thanks,
Chris

[Linuxhippy]

Hi again!

I’ve just reported another bug, RoundRect renderes exactly 1px too high when using the OGL pipeline.
The id is: 421444 - but since I reported it just today I do not expect to get answer soon

Regarding the createImage will return BufferedImage, wouldn’t it be possible to release the memory hold by the BufferedIage itself, if no one draws on it for a long time (and its blitted a lot?).
If something should be drawn again to such an optimized image, java cold detect this, render from the textture->bufferedImage again and could set a flag to never again try to save the system-memory.
Because I think textures are not allowed to loose their content, aren’t they?

lg Clemens

[campbell]

[quote]Hi again!

I’ve just reported another bug, RoundRect renderes exactly 1px too high when using the OGL pipeline.
The id is: 421444 - but since I reported it just today I do not expect to get answer soon
[/quote]
Thanks for your report. I evaluated it as a duplicate of a couple other existing bugs, which we hope to have fixed in Mustang.

Regarding the createImage will return BufferedImage, wouldn’t it be possible to release the memory hold by the BufferedIage itself, if no one draws on it for a long time (and its blitted a lot?).
If something should be drawn again to such an optimized image, java cold detect this, render from the textture->bufferedImage again and could set a flag to never again try to save the system-memory.
Because I think textures are not allowed to loose their content, aren’t they?

This is something we’ve considered… OGL textures are not supposed to lose their content, but I’m not so sure this is guaranteed, especially after display changes. Also, it’s not easy to read back from an OGL texture object into system memory (it can be done, but you need some available offscreen VRAM to do this, which isn’t always guaranteed). For these reasons and a few others, we’re not likely to implement anything like this soon. Are you simply concerned with memory consumption of managed images?

Thanks,
Chris

[princec]

The way OpenGL works is that when you call glTexImage2D it takes a copy of the image you point to and places it in system RAM, and manages it forever after for you, putting it into and out of VRAM as necessary. However I have encountered some really old, really shitty drivers from Matrox that failed to take a copy and actually kept ahold of the pointer. But my advice is simply to ignore drivers that do this as it is completely incorrect behaviour.

Likewise glCopyTexImage2D doesn’t need VRAM to copy into, it copies the data back out into system RAM for you to do with as you please.

So basically if you were to back a BufferedImage with a GL texture you may as well free the heap RAM (which is what I do in my games)

Cas

[Linuxhippy]

I was just concerned since it seems not to be possible to hold blit-only images as icons, there’s always the bufferediameg data arround.

I do not only think about games but also about applications using many icons and so on.

lg Clemens

[campbell]

Nvidia

• Java 2D GradientPaint is very slow on GF2-based boards

ATI

• Gradients rendered incorrectly in Java 2D apps

Good news on these issues reported earlier. We found a slight tweak that makes GradientPaint performance on GF2-series boards consistent with other boards. So instead of ~3 fps for demos involving GP (with AA disabled), you should now see ~400 fps. (The GF2 series includes chips like GF Go 440, GF MX 4000, etc, so Clemens, you should see a big improvement here.) Also, as icing on the cake, this change also makes gradients render properly on ATI Radeon series boards (instead of just rendering black).

The bugid for this change is 6251468 and should be visible on the JDC tomorrow. This fix along with a bunch of others will be available soon in Mustang-b33.

Thanks,
Chris

[Linuxhippy]

wow - great! Thats of course the best solution, better than doing it in software

Maybe this will also speed up the ozean theme a bit - great.

Thanks, lg Clemens

[Linuxhippy]

Hmm, just came arround another strange issue with Opengl enabled.

I have some UGLY code that does water-animation, basically it does nothing more than first create some wave-images of the original picture and after this it blits them over and over.

When running on X11 I don’t have any problems, and also with OpenGL and many wave-images (more than 6) everything works.
This happens, because the code allocates one big image and just moves it to negative x-coordinates to just draw the area which should be shown.
If using more than 6 images, the image reaches over 4096 pixel -> no accerlation…

If you want I could send you the code as PM, should I?

lg Clemens

[Spasi]

[quote]If using more than 6 images, the image reaches over 4096 pixel -> no accerlation…
[/quote]
You’re surpassing the maximum texture size supported by modern graphics cards (4096 on NV, 2048 on ATI).

[Linuxhippy]

well I know - if I use big textures I do not get accerlation -> the it works. Re-read my post!

However I was able to track down the problem, it was also caused by the no-VolatileImage-Size-Bigger-Than-Window bug, but it was not my code so I did not know it was caused by this problem…

lg Clemens

[selendic]

OK guys, just to notify you, it seems that OGL acceleration doesn’t want to start on Linux with newest NVidia drivers (1.0-7664).

[Linuxhippy]

same here, so not even pass the initializing stuff

[campbell]

@selendic

OK guys, just to notify you, it seems that OGL acceleration doesn’t want to start on Linux with newest NVidia drivers (1.0-7664).

Thanks for the post. I was planning to install the new drivers today. I tried their beta drivers a few weeks ago and everything was okay, so I’m not sure what happened yet. Really, this sort of thing should not be happening, since Nvidia should be running our “basic acceptance test” before shipping new drivers. Grr… I’ll contact them to find out what happened.

BTW, I’ve been on jury duty for the past couple weeks, and it will go another couple weeks, so bear with me. I’m still finding some time to make some nice improvements to the OGL pipeline though.

Thanks,
Chris

[swpalmer]

@campbell

BTW, I’ve been on jury duty for the past couple weeks, and it will go another couple weeks, so bear with me.

Was the perp wearing WIDE pants that were halfway down his ass? If so then he’s definitely guilty, specially if he wasn’t wearing a shirt at the time of the crime and has lots of tattoos.

[campbell]

@selendic

OK guys, just to notify you, it seems that OGL acceleration doesn’t want to start on Linux with newest NVidia drivers (1.0-7664).

FYI: The relevant bug report should be visible on bugs.sun.com tomorrow under bugid 6281130. I’ve already been in touch with the Nvidia engineers. The bug report has more information about the underlying issues. I’m meeting with them this week to ensure regressions like this don’t occur in the future.

Thanks,
Chris

[campbell]

@campbell

@selendic

OK guys, just to notify you, it seems that OGL acceleration doesn’t want to start on Linux with newest NVidia drivers (1.0-7664).

FYI: The relevant bug report should be visible on bugs.sun.com tomorrow under bugid 6281130. I’ve already been in touch with the Nvidia engineers. The bug report has more information about the underlying issues. I’m meeting with them this week to ensure regressions like this don’t occur in the future.

Thanks,
Chris

Update: Nvidia has released a minor driver update (7667) for both Linux and Solaris that resolves the initialization issue described earlier. A more complete fix will come in Mustang sometime next month, but with 7667, both JDK 5.0 and JDK 6.0 apps should work once again with OGL enabled. There are still a couple remaining issues in 7664 and 7667 that affect the OGL pipeline, but they are minor and should be fixed in their next driver release.

Chris