Open Medal of Honor (BETA)

@hotrod

Of course we must not forget that it is still a beta version. At first I thought it was the game engine that might just be poorly optimized, but since you have already described that it runs very well under MorphOs on a PowerMac 2GHz, it confirms what I could see on my X5000/40 2.2 Ghz.

I personally would be interested in some numbers, you can do this simply by opening the console in the game and entering “fps 1” here, preferably on your MorphOs machine on PowerMac.

Yes we are using slightly newer graphics cards, but the drivers are not the best so it is confirmed that just lightining is a big problem at the moment.

I have also left you a video of how it works under an X5000, the CPu load is 99% which causes problems with the background music stopping from time to time. You see it once with maximum details and resolution and the other time with minimum detail level and still the FPS rates sometimes go below 14 FPS.

Pay attention to the FPS counter on the lower left side.

@Maijestro
Quote:

Yeah, something bad happens somewhere and it was discussed few years ago , but it's unknown still who is guilty : gl4es, ogles2 or warp3dnova. All i found is that when game are 3D, and you meet some "open area" with lot of textures, FPS drop is very-very visibly.

For example in "Return to Castle Wolfenstein", while you in most cases have 50-60 fps, in the stage where the funicular transports across the abyss from mountain to mountain, you just drops to 5FPS.

Or for example in DOOM3, there also some places where FPS drops much.

Or in minigl version of old SuperTuxKart there a level with more than usual textures, which drop FPS much.

Or, even Heretic2, there were few places where FPS drops to 5 fps as well.

Something wrong somewhere, that for sure.

As i remember, Hans doing lot of tests, and found that even our Bandwidth between CPU and GFX are lower on 4 (!) or so times than we can expect. The reasons is unknown and wasn't found.

@rjd324

https://github.com/openmoh/openmohaa/issues/301

@Maijestro

What I can say is that it's really stable and might be as good as it gets. These problems got nothing to do with the port lite stated. It's been there since AOS 4.0, with the old computer and AOS 3.x it was fine so when new hardware arrived a huge speedboost was expected but it never happened. It was barely faster at all or possibly slower than the same game on much slower hardware.

Not complaining, I have confidence that it might be fixed one day but it's good to always have that it mind.

Anyhow, it's what it's. If you got fast enough hardware and can look past the FPS-drops you can still enjoy it while waiting for progress in other areas and if it gets too frustrating you can always relax gaming on some other device, there are tons of choices. Yes you wanna game on the machine that you love and own, just saying that it might be a relief sometimes. At least that's what I do :) . I enjoy 2D-stuff mostly that runs well on the A1222. Thankfully most things works really well :)

I personally am not complaining about it, I am just sharing my experience with AmigaOs4.1 and all the 3D stuff. Just being able to run games like Medal of Honor on NG Amiga is impressive to me.

Nevertheless, I am satisfied with my hardware and also with AmigaOs4.1, but of course we could get a much better experience with optimizations.

No I get it, it's really good to be able to be open about how things are and talk about it, I wasn't complaining either, just sharing my thoughts and experience.

I am thinking that it will be addressed at some point. I saw your video and would consider it to be playable so enjoy :)

Besides, can you skip through the first tutorial? Under MOS I get to place where I shall place a bomb on a tank and when it goes off it freezes and I need to reset.

@hotrod

I played the tutorial from start to end and there were no problems with version 81.1 beta under AmigaOs4.1.

Did you also play it under MorphOs with 0.81.1 or was it perhaps an earlier version?

@Maijestro

I created a quick and dirty video of my X5000/20 running OpenMOHAA on MorphOS. The GPU used is a 256MB X1950 so not even close to the RX power we have available on OS4. But overall very playable.

@Skateman

Thanks for providing the game video and the test with X5000 under MorphOs. Impressive how well it runs with the X1950 which has only 256 MB.

Under AmigaOs4.1 I would have expected at least constant 30 FPS with RX580 and full details.

Hopefully one day the mystery will be solved why gl4es, ogles2 and warp3dnova perform so poorly under AmigaOs4.1.

Nobody seems to know the solution at the moment, HunoPPC also noticed it and reported it to Hans, but Hans is of the opinion that the drivers have no problems. This will also be the reason why we will not see Quake4 for AmigaOs4.1, so HunoPPC told me.

@kas1e

Btw i can reproduce the lighting issue with Sin.

It is actually worst on MiniGL with novabridge, there if
I enable dynamic lighting (will check what actually Sin
does there) it cuts fps in half. On gl4es renderer
it only eats 25% of the fps (still 28 fps on 1920x1080
with dynamic lighting enabled on my x1000 - very playable!)

Dynamic lighting in id Tech 2 games draws into the lightmaps, so potentially multiple textures have to be updated each frame. I guess this eats up the already limited bus bandwidth.

@Steffen, BSZili

I hope Hans can add a bit to what i say there, but:

I remember when Hans tested all the bandwidth limitations, he measured the performance inside the RadeonRX.chip driver for x5000/020, and found that something weird is going on with the X5000's PCIe controller: DMA transfer rate, was no faster than CPU transfers: It's maxing out at about 300 MiB/s, which is a fraction of the 2GiB/s theoretical max for 4x PCIe gen2.

Also were found by those tests that x5000/040 is slower than x5000/020 on copy transfers for about 30% of the 020 speed (that explain why some 3d games on 040 is slower than on 020), while this not seems to relevant, it's again show that something bad happens with PCIe controller on the initial setup.. Dunno maybe by UBOOT, or by kernel, or whatever else, but we should have at least 1.5G/s of transfer, not just 300M/s.

It looks like we are a little bit faster than "PCIE gen 1.0 x1", which give 256MB/s. And even "PCIE gen 1.0 x2" give 512MB/S which we already didn't reach.

In end of all it ends nowhere for now, only that we know that there issues with bandwidth and we not known from where they come: uboot, kernel, or whatever. But by some reasons we can't reach even fraction of PCIe gen2 limitation. And probably that is what we have when we have many textures in one frame (this can explain and lighting issues, and speed drop in games when there a lot to show, even without lighting).

@Skateman

Is your video with all graphics settings set to max? Or the default?

Maijestro's video has all settings set to the maximum possible, and it would be interesting to have a comparison with the same settings.

@kas1e

Quote:
Yeah, the measured results were lower than I expected. I still don't know if it's a hardware limitation, or if the PCIe controller isn't set up right. Or, if it's something that the driver is doing.

The biggest bottleneck isn't the number of textures, but the number of draw ops that we can shovel to the GPU per second. More textures, usually means more draw ops, because each texture needs its own 3D mesh. This is also why games slow down with large open spaces, and/or lots of objects on-screen.

I suspect that we could get higher performance if the driver used interrupts to slurp command buffers from RAM. That's out of reach for now because, in addition to reworking the command queue code, the 2D hardware acceleration would have to be overhauled to queue multiple draw ops instead of sending them to the GPU one by one. Oone interrupt per draw op would be very bad for performance.

Picasso96 (and the graphics library) is designed to send draw commands to the GPU individually, so you have to pull some serious stunts to be able to queue multiple ops in one command buffer.

It's a lot of work for unknown gain, and I'm busy with other stuff right now.

Hans

@Hans

Quote:

I don't think that will help and even then it will be faster.

Take a look at the last part of the video where I set all details to minimum and still the numbers drop to 13 FPS at the beginning of the level.

@Maijestro

Quote:
I'd just like to see a direct comparison with all variables the same.

Hans

@Hans

My settings are not all maxed out... but you can see the settings in the video. I also forgot to mention that the X1950 GPU is in the X4 slot of the X5000. (but bandwith is not the issue)