I'd like to apologize for the length and location of this post. As it covers hardware and software, I placed it in General Discussion.

As impressive as MorphOS' support of 2 and 3D rendering is many of the routines supported rely on software rendering. Use of hardware accelerated functions is limited.
I can understand how difficult it can be to write support into an OS when the manufacturers of GPUs don't want to fully document their products.
As such, MorphOS and AmigaOS 4 performance under application that use those routines (in particular video games) suffers.
Current AROS (an X86 OS) is likely to soon have better support for those functions than PPC based alternatives.
I know the development teams time is limited, but couldn't some parts of MorphOS be opened up to hasten development of better functioning components?
As more information on how to program GPUs to use hardware embedded functions (rather than software routines) for rendering becomes available, the 2 and 3D libraries could be greatly accelerated.
Its irritating to see comparisons of frame rates on development systems (like the Natami) that compare the potential frame rates (on a system that is not available) unfavorably with frame rates under MorphOS and AOS (on systems that exist for purchase).
As we have more than adequate CPU performance, the low performance of our graphics rendering is primarily due to driver deficiencies and limits on what cards we support.
If this part of MorphOS was opened up, then we could work towards matching (or beating) the rendering performance of alternative systems.

You probably didn't see real world results, though. :)
AROS is still not using the most common hw accelerations in gfx drivers (no overlay, slowness of the supposedly accelerated native drivers and so on, ...). Not that long ago, because of that lack of hw acceleration (or whatever else?), AROS on a recent PC was so crippled it was actually slower to play a 720p movie than a miserable Pegasos2 (pure decoding was obviously much faster, but blitting was infinitely slower than the Peg2/MorphOS setup). Results were improved since, but they're still quite bad.

As for the natami, if you refer to that shoot em up benchmark (which was done on OS4 anyway, not MorphOS), it was really very biased, comparing vapor (i.e the not yet existing hardware supposed to be accelerated for these very specific operations) against a plain generic software-rendered port (likely very badly written considering the results on a G5). In one word, meaningless.

Anyway, to avoid any confusion, what do you think is purely software-rendered in MorphOS, exactly?


[ Edited by Fab on 2010/5/20 4:56 ]

Yes I've already used the term biased with the Natami developers (and Gunnar who was responsible for those posts was duly offended).
All rendering done in the comparison does seem to be software based. For example, the PS3 fps was a low double digit figure (based on running software under Linux which doesn't have access to hardward rendering).
I am impressed with the AROS team's ability to get the GLxcess demo running though. And it does look like their support on Nvidia video cards may soon outperform our support on ATI video cards.
They have an advantage in the number of developers and an open source approach (while MorphOS probably has BETTER developers but with limitations due to their smaller number).
Personally, I'm just finding it frustrating that rendering on anything other than a Microsoft or Apple based system (using similar hardware) faces so many obstacles.
We really should have several TIMES faster performance on some functions.

OK, as to what is software rendered, even on cards that MorphOS supports for hardware acceleration almost everything. At this point neither MorphOS or AmigaOS even uses the shaders built into modern video cards.
I'll admit we have it better than AmigaOS users, where just getting basic control of the framebuffer and creating a display is considered adequate, but I'd be willing to bet that if you look at most MorphOS functions they still are primarily driven by the CPU.
With so much else to focus on, I'm not sure that the development team has the resources needed to constantly rework/improve video rendering.
That's why I suggested opening up this one part of the OS.

While you are right about shaders support, i think you underestimate what's hardware-accelerated on MorphOS, and on the other hand you overestimate AROS performance on that topic (as well as the actual number of core developers for AROS, that can be counted on a hand).
2D/3D support on MorphOS is a lot more than just a plain framebuffer (and that's true for OS4 too, fortunately): for the most obvious that i could think of, blitter, alpha ops, ... (the gfx drivers developers would answer much better than me on that topic). But that's not so true for AROS, where even some plain VESA drivers are actually faster than the supposedly accelerated drivers (??). About 3D, you should also keep in mind Gallium3D is still rather primitive for now, not very efficient and it doesn't support a wide range of chipsets either. And last but not least, AROS is far from actually using Gallium3D for anything else but GL apps (meaning all the windowing system will still stay very slow for quite some time). For Nvidia cards, I believe they also play with "Nouveau", but it's still quite early too, and only for 2D.

And by the way, about glexcess demo, it was compiled for MorphOS, and runs nicely (several times faster than OS4 in parts like tunnel or mountain/water scenes). I don't remember if the demo provides some benchmark indication, though.


[ Edited by Fab on 2010/5/20 6:18 ]

Quote:

Scaling/stretching, tinting, gradients...

Quote:
And I predict that they're unlikely to have better support, at least not better than MorphOS.
Quote:
Some components are open already. They mostly see very little advancement. CyberGraphX and 2D/3D drivers will not be open.

Quote:
The comparisons get interesting when you compare the frame rates of the same HW setup between different OSes. AROS has been said to become available for PowerPC for a long time now. When it does, it will be interesting to compare 2D and 3D performance betweem AROS and MorphOS.

[ Edited by Piru on 2010/5/20 10:16 ]

Just out of curiousity, does MorphOS allow programs to access hardware as workbench hacks used to in the good ol' days? Or does that kind of access have to be negotiated through the OS? How well documented is the hardware that MorphOS runs on?

Quote:

Gunnar is an EXPERT on software optimization with proven results over the years and working at IBM for quite a while. I would also be offended in his place.

Quote:

Excuse me, just how did you get to that conclusion, that MorphOS has BETTER developers -and why the caps anyway? This isn't a competition, AROS and the Natami project are open and they attract good developers from everywhere. And it's easy to estimate the worth of each developer's work.

Quote:

I have many times advocated in favour of opening MorphOS.

Seriously, comparing cpu-based aproach to some nonexisting natami aproach is silly. Morphos is perfectly capable to render this game at high framerates. Only thing you have to do is to use proper tools. Using first random library and basing all comparisions on that is silly. Use OpenGL and you will get all hardware accelerated functions you need for such a simple game. From what i see you don't even have to do that much and simply use system bitmap blits which are perfectly fine for rendering bitmaps with alpha channel using hardware blitter. Picking SDL and using it to blame whole system/platform is just spreading fud/bs.

Quote:

Reg. Gallium3d, phoronix ran some benchmarks that showed Gallium is making very good progress, in some cases it's faster than Mesa for R300 ATI chipsets. In fact only recently it has integrated MSAA (antialiasing). Right now it's not faster than Mesa or other 3D engines, but I believe this will soon change. Adopting Gallium3D was a very smart move from the side of AROS.

Quote:
Allow? Well MorphOS doesn't specifically try to prevent it. In practice, however, any such access is a very very bad idea and will likely end badly.

@Feanor

For an expert, he really does silly benchmarks. I hope it doesn't extend to his actual work on NATAMI.

Quote:

Har, I'm offended by that claim. <invoke Andreas-search-o-matic />


- CISC

Quote:

I don't know what you mean by "silly benchmarks", but he has done excellent work on optimizing core libc functions. He has in-depth knowledge on pretty much every PowerPC cpu out there, and can justify his choices on his code with numbers.

How's that considered silly?

Quote:

I could also provide links if you asked, what's so unbelievable about my claim? Yes, I know Gunnar, and yes I know -some of- his work. He's really good at software optimization, enough so that I can call him an expert. He also works at IBM -that's no secret. So what exactly is the problem? Anyway, I'd rather not talk about someone else behind his back, I'm sure he would find the argument totally irrelevant anyway.

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=2&topic_id=4637&sortname=&sortorder=&sortdays=&viewmode=flat&order=0&start=20
This thread is even more fun today with existing mplayer cache2 code and Mac mini port :)

A thread from 2006? you must be joking. Anyway, I rest my case, I don't know if Gunnar reads this or not, but the thread failed to convince me that he's NOT an expert -I know he is anyway.

By the way, to have an idea how unoptimized this shoot em up can be, please consider that it's roughly comparable to the arcade game 19xx on CPS1 (or let's say strikers 1945 on Psikyos hw, since there's some 32 bits alpha composition there). What are the results:

~10fps on a Mac mini G4 for this native 1942 extreme game
~160fps on a Mac mini G4 with MAME running 19xx (or ~100fps when running strikers 1945).

The small difference being MAME additionally emulates a whole 68000 (or SH2 for strikers 1945) and video/audio chipset, and yet proves to be several times faster than this native game. Don't you see some problem?

(ok this 1942 game might have a higher resolution than these arcade games, but it's no excuse for such a HUGE difference of performance).

[ Edited by Fab on 2010/5/20 17:13 ]

Quote:

Yes, of course. I wouldn't compare a native game with an altogether different -but similarly looking- MAME game. They may even look the same but they could be -and probably are- entirely different.

As to Gunnar's level of expertise, he's probably one of the most knowledgeable people in the Natami development team (which is not an open system - BTW).
However, Gunnar posted low fps on PS3 systems (primarily from his use of Linux - rather than the PS# SDK which as an IBM employee I'm sure he's familiar with).

As, to my speculative statements about MorphOS 2 and 3D drivers, purely speculation on my point (since they're closed). And some of the speed deficits are obviously due to the current focus on older GPUs. Even w/o shader support, more recent GPUs at higher clock speeds with more execution units would give us higher performance.

Obviously, I've now got two forums stirred up over postings that weren't as well considered as they could be.

My initial impression that the postings on fps is an unfair, biased presentation I'd stand by. When programming on different hardware, frequently adapting/optimizing code from one platform to another is inadequate. Often, it benefits the programmer to approach the desired end result via totally different code. It appears that in 2D/DMA based operations, if they ever get it finished, the Natami may have an advantage.

However, if what you've stated is true, we have support for features they aren't considering (alpha ops was just recently part of the topic that brought this matter up).

I'm not going to try and compete with people at Gunnar's level, and I don't want to use an X86 based OS for development (which does seem to be the main focus of AROS).
But it will be interesting to see what can be done to match other Amiga like OS/platforms.
MorphOS with its JIT compiler still supports 68K code, and PPC code is more powerful than 68K (and less complex than X86). So much (if not all) of what competing systems can do can be done under MorphOS.

Instead of serving as Devil's advocate, I'll try and be patient and see what future hardware support is introduced. With more powerful Apple models and better video cards I'm sure MorphOS will still offer a competitive, stable (and available) platform.

"As, to my speculative statements about MorphOS 2 and 3D drivers, purely speculation on my point (since they're closed)."

And why do You have to speculate? Simply ask or try. All functions supported by MorphOS OpenGL implementation are accelerated by hardware. And it certainly beats feature-wise what the natami will (or will not) provide. We can talk about speed when the other party delivers.

" And some of the speed deficits are obviously due to the current focus on older GPUs. Even w/o shader support, more recent GPUs at higher clock speeds with more execution units would give us higher performance."

I don't know about what speed deficits you are talking about. If You mean the ones mentioned in natami thread then they are purely because of wrong tools being used for the job. even old gfx cards (as the ones supported by MorphOS) are perfectly capable to render such game. No need for shaders. Just simple blending operations.



[ Edited by kiero on 2010/5/20 23:17 ]

@Jim

With this engine, the shoot'em'up would probably not give great results either on recent PC/Linux/Windows/OSX setups (see that figure of 30fps on a G5 system, that's just ridiculous), even though these systems all have the hardware accelerations you're telling we lack on MorphOS. But that's quite obvious since this engine is totally cpu-driven.

Any properly designed shoot'em'up would use blitter and compositing facilities to achieve a decent framerate, which MorphOS obviously provides.


[ Edited by Fab on 2010/5/20 23:47 ]

Actually, that has been a continuing point of contention between Gunnar and myself. His fps quotes on alternative (PPC) systems were based on the use of SDL (software rendering).
His argument was that AOS 4.0 didn't support Aplpha blits. If that's true than MorphOS may have a definite advantage over AOS.
What I don't understand was the use of SDL on Mac OSX and the PS3. OSX supports hardware acceleration and when developing with Sony's SDK the PS3 does as well (not under Linux like Gunnar used).
Gunnar's only other objection was the lack of 256MB of video memory on most PPC systems. My own system has a 256MB video card.
And I don't understand the G5 fps rating either, since their Powerbook rating was much higher.
Gunnar admits in a post of his own (on PPC ports) that the comparison may be "unfair".
I'm not happy with this "my dog's better than yours" attitude amongst different factions of the Amiga market.
It may require some reworking, but most apps should be easier to port amongst the different Amiga-like systems then apps from other OS' are.
Looking at where we are, I may have underestimated how well MorphOS supports rendering functions. We're not quite at OSX's level of support, but its better than I assumed.

[ Edited by Jim on 2010/5/21 0:26 ]

@Jim

Btw, I've discovered that thread where you discuss that on Natami forum.

"OS4's support for hardware acceleration is limited (I haven't gotten a response back from MorphOS dev. but some of the users believe there is support via their OS for Alpha ops). "

In case you wouldn't know, piru, cisc, itix, henes, kiero and I are in MorphOS development team. That's even indicated just below our nicks, actually. :)
And that hardware acceleration support is a bit more than just a "belief".


[ Edited by Fab on 2010/5/21 0:40 ]

@Jim

1. that 1942 clone is badly programmed as it should run *much* faster on *all* the hardware that was tested.
2. Gunnar's coding skills may be great but he was not able to perform a good analysis of the available hardware and the requirements of the game. It doesn't matter if you optimize to the maximum a small loop if you choose the wrong libraries and tools. That means he may have done a bad analysis. His past claims about coldfires running existing 680x0 software faster than 060 were absurd and based on imagination.
3. Using software rendering when OpenGL and advanced 2D functions are available may be fun but it's not clever to use it to talk about unused 2d/3d functions.
4. Your claims about MorphOS 2D/3D acceleration system slowness are ridiculous because you base them on a bogus benchmark that is software only.
5. If you had proposed running QuakeIII on the vapor-3d chipset of Gunnar at least we would have a game that doesn't use our hardware as an expensive framebuffer
6. AROS 2d/3d acceleration is still far away from MorphOS, they still don't have Overlay and 2d/3d is not s integrated as it is on MorphOS. Unfortunately there are just a few coders working on AROS.
7. Everyone would like to have pixel shaders and all that fancy stuff but we'll have to wait. Future MorphOS Radeon drivers shown by Bigfoot will rock. Keep in mind supporting latest pixel shaders is useless since we don't have PCIexpress hardware to use them.

Conclusion: feel free to provide some meaningful benchmarks instead of an amateurish badly programmed game.

PS: please donate a QuadG5 for each MorphOS Team member so they can decide if they want to add support for G5

Quote:

On 2D MorphOS is probably ahead of OSX (check out EUAE... they use OpenGL and it's slower than MorphOS Overlay version). On 3D MorphOS may lack support of latest shaders but depending on resolution in some 3D benchmarks (quake3) MorphOS even runs faster than OSX.

One question... when was last time you used MorphOS? it looks like you had not used it for a long time since you seem to believe all propaganda coming from outside.

[ Edited by Crumb on 2010/5/21 2:04 ]