Hello.

I'd like to know if someone has already made tests to compare 2D rendering performances between these 4 system on Amiga OS 4:
- Use MiniGL Primitives to render 2D.
- Use Cairo to render 2D
- Use Intuition Blitting to render 2D
- Use Composition mode.

What is the faster ?
What is the "most complete" in parameters, options and capabilities ?
And the average ?

Thank you.

Kindest Regards,
AmiDARK

@AmiDARK

I have no stats to present to you but to hazard a guess I'd say Composition mode.as you put it.

My reasons why:

MiniGL was an incomplete GL API sitting above Warp3D hardware drivers IIRC.

Cairo is said to use software rendering.

Intuition Blitting may use CPU even if PPC optimised.

Composition mode.uses to 2d acceleration so IMHO the best.

Clarifications welcome.

@Hypex

Quote:

MiniGL was an incomplete GL API sitting above Warp3D hardware drivers IIRC.

Yes, something like that. It's "more and less" OpenGL ES1 state (got some options that ES1 hasn't, like totally obsolete immediate mode, and probably also lacks something)

The thing that's most important and wasn't mentioned: What are you going to use it for?

OpenGL behaves the best "with itself", it's generally a REALLY bad idea to mix OpenGL blitting with "blitting with anything else". Of course you might be able to use an API that uses OpenGL internally together with "direct" OpenGL use (might have issues with context initialization etc.)

And last but not least, even if mixed OpenGL / non-OpenGL blitting does work now, it doesn't necessarily:
1)Work with all graphics cards.
2)Work in the distant future, when new OpenGL drivers are released.
3)Also to make it work more reliably, you need to "slow down" OpenGL (glFlush())

OpenGL is at its best (in 2D blitting) when:
1)You blit the same images over and over again, and know when you need to update the graphics to be blitted (to minimize the relatively slow RAM => GFX RAM transfers). If you need to update the data every frame, that is going to slow down (note that this happens also when the API cannot know, if the data has changed. Then you need to update "just in case")
2)You need to do stretching, flipping, rotation (in 2D or 3D), per pixel transparency, tint etc. - those come "almost free" with OpenGL.
3)You want to have a "virtual resolution" (say, 320x200) that the game scales automatically to window dimensions.
4)You avoid functionality like glReadPixels() and glWritePixels() which are really slow. Especially if done several times per frame for some weird reason. I'd recommend using glReadPixels() only for screenshots. For anything else, it's too slow. For glWritePixels() I can't even think of any valid usecase (maybe some debugging?). Of course with limited GL functionality, glReadPixels() can also be used as "poor man's render to texture".

Of course this is all assuming there's 3D acceleration.

Last edited by Jupp3 on 04-Apr-2013 at 12:51 PM.
Last edited by Jupp3 on 04-Apr-2013 at 12:50 PM.

@Jupp3

Quote:

Yes, something like that. It's "more and less" OpenGL ES1 state (got some options that ES1 hasn't, like totally obsolete immediate mode, and probably also lacks something)

I only found out about ES recently when making a new build of Stratagus.

Quote:

The thing that's most important and wasn't mentioned: What are you going to use it for?

On that nore I tried activating OpenGL mode in a Stratagus compile. It picked up somehow I had GL support so enabled GL and I added the GL libs. But all it did was crash in the end. Some gfx were blitted but text was not.

In the routine it looks complicated. It calls all these GL routines just to stick an image in the framebuffer. By comparison the routine doing a standard blit looked more efficient! It made me wonder what the point of using GL was. For 2d at least.

I also concluded that a GL API that only supported 2d and used the compositing would be a perfect solution for OS4.1! Of course writing an API that is simply a wrapper and could get in the way by its design may not work that great.

But we do need a way to run SDL apps without them hogging the CPU and eventually killing the system. Or mouse in my case. Unfortunately Stratagus is still in this state. It's only a 2d game. Ridiculous!

Last edited by Hypex on 05-Apr-2013 at 12:37 PM.

@AmiDark

Our cairo library are very old compared to the latest available.

The latest versions are more fast than our available version... various optimizations, fastpath, etc...

I remember that one of the Frieden said that cairo is partial hardware accelerated, but can't remember what thread.

_________________
retired

@AmiDARK

There is no one size fits all solution at this time. It all depends on how many 4.1 machines you want to cover and what feature set you need.

* Compositing is fast and efficient on Radeon cards, but is not available on older video cards.

* MiniGL only works on systems that already have Warp3D. Until a driver is released for the HD cards, this is not an option, but it covers more hardware than compositing alone does.

* Traditional intuition is limited in functionality.

What I would suggest is that you consider an abstraction layer. Decide what features you want for a 2D rasterizing engine, make it an abstract interface and create more than one runtime implementation. This approach has served me well in the past.

However, for basic 2D, forget MiniGL. There's nothing it can give you that your own basic 2D transformation functions and Warp3D can't give you with more cycles to spare. Warp3D already operates in screen space and can throw stuff at the screen with much lower overhead than MiniGL. You have total control over the hardware locking too.

Last edited by Karlos on 05-Apr-2013 at 07:02 PM.

_________________
Doing stupid things for fun...

@All :
Thank you for all your answers, it confirmed what I though...
I think it's a major problem on our actual AmigaNG ... It's that we can't optimise something for "all" amiga and due to this, if we want to "get the best" for all AmigaNG, we must add more code to our projects (and it's not always short to do).

Kindest Regards,
AmiDARK

@Hypex

Quote:

In the routine it looks complicated. It calls all these GL routines just to stick an image in the framebuffer. By comparison the routine doing a standard blit looked more efficient! It made me wonder what the point of using GL was. For 2d at least.

What would the point of using OpenGL, then using some "non-OpenGL" routines for blitting? Doesn't make any sense to me...

Many games require 3D, so practically all consumer oriented gfx chipsets are optimized for that, and good 2D performance comes as "free extra".

Honestly, I can't see where this "OpenGL is complex for 2D" comes from. Are you comparing againist AmosPro's Paste Bob or what?

OpenGL just is the most widespread hardware accelerated graphics API. It doesn't really matter it's "3D", you can always just forget the third dimension

@Karlos

Quote:

* Compositing is fast and efficient on Radeon cards, but is not available on older video cards.

It falls back to software mode if the hardware doesn't support it, so it works everywhere. The transformation parts of it need hardware support but simple blitting/resizing don't. NetSurf OS4 uses CompositeTags() extensively so I think somebody would have mentioned to me by now if it didn't work on certain hardware.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Chris_Y

The problem is that software compositing is not a performant solution, especially if you have to do any blending effects that require framebuffer reads. Those can be insanely expensive, slower than Chip RAM access on some machines. Compositing isn't even fast on all Radeon hardware. On my 32MB R100, a 1280x1024 screen with a few large windows open soon runs out of VRAM and then chokes with it enabled, at which point, things got *very* slow and jerky.

The question was specifically about performance. If you want the best performance on all configurations, right now there is no choice but to create an abstraction in your library that can be implemented in different ways for different configurations.

@Jupp3

Warp3D, used as a pure 2D rasterizer simply obliterates MiniGL, simply because MiniGL, even in 2D mode has a full GL pipeline in software to worry about. If you stick to V4 or V5 vertex array calls, you can throw a lot of geometry at the screen and it's typically limited by the bus transfer rate on faster CPUs. And that geometry is already in raster coordinates to begin with. It isn't transformed or clipped (other than scissoring if you use it), it's just pushed straight to the GPU, no questions asked.

The traditional 2D components of MiniGL (i.e. rectangle blitting) aren't necessarily any faster than standard graphics library and can even be slower.

_________________
Doing stupid things for fun...

@Karlos

Quote:

The problem is that software compositing is not a performant solution

True, but it's no slower than BltBitMap, and if hardware compositing isn't supported, the chances are that Warp3D/MiniGL aren't either, so there's no way of making it any faster.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Karlos

Quote:

Warp3D, used as a pure 2D rasterizer simply obliterates MiniGL, simply because MiniGL, even in 2D mode has a full GL pipeline in software to worry about. If you stick to V4 or V5 vertex array calls, you can throw a lot of geometry at the screen and it's typically limited by the bus transfer rate on faster CPUs. And that geometry is already in raster coordinates to begin with. It isn't transformed or clipped (other than scissoring if you use it), it's just pushed straight to the GPU, no questions asked.

Considering it's "backwards compatibility only" API, I'd stay as far from it as possible.

Has it even been confirmed, whether there will be any Warp3D support for "currently (and in the future) unsupported hardware, that will get better OpenGL implementation"?

How many games / programs, there are, that:
1)Work on AmigaOS4.1
2)use Warp3D
3)Don't use Warp3D "through" MiniGL (so they can be re-compiled for any OpenGL implementation with minor changes)

I'd claim the number isn't that high, and I guess excludes f.ex. all game ports by Hyperion.

So would Warp3D support be worth it? You tell me. Afaik, there's a software implementation for programs "you absolutely need to run" anyways.

It's long time since I have touched MiniGL. Would it be possible to write a wrapper for it that will use any other OpenGL implementation instead (and have nothing to do with the deprecated Warp3D)?

@Chris_Y

Quote:

Chris_Y wrote: True, but it's no slower than BltBitMap, and if hardware compositing isn't supported, the chances are that Warp3D/MiniGL aren't either, so there's no way of making it any faster.

Not so. There are more cards (mostly in classic systems, but a few NG users might have Voodoo also) that support Warp3D than support compositing. And cards like the R100 and R200 support both.

_________________
Doing stupid things for fun...

@Jupp3

Right now, and probably for the foreseeable, there simply is no alternative to Warp3D for R200, R100, Voodoo and Permedia. Gallium is for R300 and above.

In the future, I'm quite it will be relegated to some wrapper API around a more up to date GL-like implementation. However, that might never happen on the above hardware.

Like it or not, Warp3D will be around for longer than anybody would really like. However, it does have it's charm and high speed rasterizing is certainly one of them. And for pure 2D, all MiniGL does is to add needless weight to that process.

In case anybody is misunderstanding my advice. Never write your own library software to critically depend on any particular graphics implementation if you can avoid it. A 2D library with backends that can be swapped out at runtime involves more work, but is going to be useful to more people.

_________________
Doing stupid things for fun...

@Jupp3

Quote:

What would the point of using OpenGL, then using some "non-OpenGL" routines for blitting? Doesn't make any sense to me...

That's not what I was saying. The code doesn't work together. One is the SDL version, the other is the OpenGL version, and I was comparing the code from the same sources.

Quote:

Honestly, I can't see where this "OpenGL is complex for 2D" comes from. Are you comparing againist AmosPro's Paste Bob or what?

I was comparing a routine using SDL to blit against another routine using GL to blit from Stratagus.

The SDL routine was straightforward with a few lines. But the GL routine called all these functions to do the job.

I could compare to AHI where you load sounds and AHI loads it into the sound memory so the sounds are local. With GL it should be the same with the images loaded into texture memory. All one should have to do is program the API to blit from that texture directly into frame buffer at said offset But it called a load of routines to do a simple job. Perhaps the code wasn't optimized.

So does that third dimension always complicate things or can a blit be done as a one liner like Amos Paste Bob?

Last edited by Hypex on 18-May-2013 at 06:42 AM.