@Cool_amigaN Quote:

True, on 1680x1050x32bit Sam is completely unusable, leaving you from 4-15 MB GFX Ram only with only few drawers and OWB open. The situation turns out good only when using 16bit (e.g same resolution, with same amount of opened drawers and OWB tabs I get around 35-38MBs). But using 16bit instead of 32 in 2009 isn't really a progress, instead is a step bakwards, correct?

I think it fair to say that Sam440ep's built-in gfx-card is not ideal for such large resolutions.

HOWEVER, if you turn Compositing off, then such a screen will only use 6.7MB of memory, meaning you can fit 9.5 such screens in it's 64MB of memory. Surely this should be enough for pretty much everyone? This is why I turned compositing off for everything except Workbench's screen.

So it is really OS4's Compositing that is the problem, not the Sam440. Basically the Compositing is implemented kind of badly, so that it does not handle low-memory conditions well. What it should do is flush the Least Recently Used stuff from graphics memory, so that the current screen(s) can make full use of the graphics memory.

BTW, I cannot usually tell the difference between 16-bit & 32-bit screens.

Last edited by ChrisH on 16-Feb-2009 at 10:09 PM.
Last edited by ChrisH on 16-Feb-2009 at 10:08 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

i have to say that i used to have a peg2 g3600mhz and it wasnt slow at all. in fact only a few sdl games were slow on it (robin hood, weshnot, etc), but the system was comperable to the g4 in system operation speed, even with mos2.x and layers3d on. sam has got a 667mhz cpu, fast bus and all, i guess its almost the same category as the peg2 with g3. so if your sam is slow that might be a problem with your system, bad hw component or so, not the sam weakness i guess.
but prove me wrong:)

Last edited by $adddam on 16-Feb-2009 at 10:31 PM.

@ChrisH

Quote:

I think it fair to say that Sam440ep's built-in gfx-card is not ideal for such large resolutions.

Rather kind way to express it. How about : The on board gfx of sam isn't ideal for modern resolutions?

Quote:

HOWEVER, if you turn Compositing off, then such a screen will only use 6.7MB of memory, meaning you can fit 9.5 such screens in it's 64MB of memory. Surely this should be enough for pretty much everyone?

Look at what you are saying here. Meassuring every MB of the gfx, on a modern computer, so we can save some for use for other applications?

Quote:

So it is really OS4's Compositing that is the problem, not the Sam440. Basically the Compositing is implemented kind of badly, so that it does not handle low-memory conditions well.

From when a feature of an OS becomes problem? Compositing on or off will save you some MBs of the gfx, won't add up at the amount you allready have. 64 MBs are way too low and I can't believe we are arguing about that subject here.

Quote:

BTW, I cannot usually tell the difference between 16-bit & 32-bit screens.

But I can..

Now, I downloaded and run a benchmark utility from OS4depot (it's under Utility/Benchmark) called sdlbench (it does what its name implies :P).

The results between a A1XE - G3 800 Mhx and a Sam400ep (at the Sam, none background processes were taking part (exept limpiclock and push4dock)):

320x240 320x240 640x480 640x480
software hardware software hardware
Slow points (frames/sec): 9.24885 190.476 1.12029 49.6894 -(A1)
2.65076 156.863 0.33953 41.8848 -(SAM)
Fast point (frames/sec): 236.599 101.668 56.8636 25.4397 -(A1)
89.9508 83.252 22.7132 21.312 -(SAM)
Rect Fill (rects/sec): 18789 85333.3 5461.33 33573.8 -(A1)
7501.83 110703 1980.66 74472.7 -(SAM)
32x32 blits (blits/sec): 51848.1 120471 50567.9 117029 -(A1)
26771.2 107789 20589.9 107789 -(SAM)

The G3 800Mhz outperforms the 440ep almost in every aspect while in some cases I get half or 1/3 of the perfomance of the A1XE - G3800Mhz.

edit: Hmm, The results do not display well, I will try and take a screenshot and upload it in a few hours, when I get back.

Cheers!

If a moderator can fix, please be my guest!

Last edited by Cool_amigaN on 17-Feb-2009 at 01:01 PM.

_________________

I don't know which programs are u using but I got no graphicmemory problem with my Sam. My resolution is 1280x1024 16bit depth and compositing is on. If I'm using AmiBlitz3 on a second screen, IBrowse, TuneNet, a shell and some open windows on the WB screen there's 50% gfx-mem left! That's enough for playing some nice games like OpenTTD & Wesnoth and playing an AVI parallel and you'll still have around 45% gfx mem available.

I dunno... but 64mb gfx is really enough for an daily used computer system. Especially if it's an Amiga without Crysis, Photoshop, After Effects and so on. ;)

_________________
Sam440ep & AmigaOS4.1 @ Morex 3677 case
---
(DaFreak of Liquid Skies & Moods Plateau)

Im sure 64mb should be more than enough for compositing to work well, 32mb should be plenty.
I used OSX 10.3 and 10.4 for a long time on an old beige G3 with a 400mhz G4 and a 32mb PCI radeon 7000 and Quartz extreme worked fine on that at 1280x1024. If that hardware can handle osx then the sam should be able to handle the OS4.1 compositing fine although im sure the two implementations are very different.

Possibly the OS4.1 system is still unoptimised as its a new feature, it may need some form of texture compression to compress any windows and screens that are not currently visible. I know OSX used such a feature and could be enabled in earlier versions although im not sure if it became a standard feature, i assume it did.

only the deveoper can know for sure why but the memory used by the compositing does seem a little excessive.

_________________

@Reth

> I'd like to know how the performance of the SAM looks like?

I tried quake on it. I got just over 50 frames per second in 800x600 with hardware renderer. So you can expect most games to be playable.

Kind regards,

Dennis

@ChrisH

Quote:

ChrisH wrote: @Reth OS4.1 certainly feels like it's flying on Sam440. However for games things are not so rosy YET: * I have seen Hyperion's good but old Q2 port, but due to some compatibility problems with OS4.1 it does not run using Warp3D (which would be fast). Instead it only runs in software mode, which for 640x480 was very smooth, for 800x600 was (EDIT) smooth-ish but not really usable for multiplayer, and for 1024x768 was not quite playable. * Capehill's more modern Q2 port (based on Hyperion's GPLed code) is Warp3D only, and runs smoothly in 1024x768. HOWEVER due to an Warp3D/OS4.1 beta bug on Sam440, everything is green :( . I believe this is going to be fixed (??). * The old Q3 port is unoptimised, has graphical problems, runs slowly & tends to crash. * Capehill's more modern Q3 port (based on the above) works a lot better (at least with 16-bit display & textures), the frame rate seems acceptable (10-30 fps) with (EDIT) geometric detail set to Low & lighting set to Vertex (everything else at max), but walking was very slow for me for some reason. I guess it still needs tweaking & optimising... I think these problems are mostly software issues, and so will hopefully be fixed eventually. * Payback 68k runs quite well. PPC version doesn't like OS4.1. * UAE runs very smoothly, but with version 0.8.28 I have not been able to get sound to play smoothly.

Nice report. Most are software problems.

_________________
ikir

@Cool_amigaN

> But using 16bit instead of 32 in 2009 isn't really a progress,
> instead is a step bakwards, correct?

No. I haven't met anyone yet who can tell the diference between a 16bit and 32bit screen by looking at it. Using 32 bit is just a waste of memory and bandwith IMO.

Kind regards,

Dennis

@A3000T

Quote:

No. I haven't met anyone yet who can tell the diference between a 16bit and 32bit screen by looking at it.

There I am...

@A3000T
I definitely notice some difference when it comes to some pictures and such.

@Tomas

Quote:

I definitely notice some difference when it comes to some pictures and such.

Sure. And it will vary depending on each user's setup, just like flaws will be more noticeable on a larger screen television.
Kodak's standards allowed for enlargement of pictures.
You can do the same experiment.
Blow up a 24/32 bit image (double twice perhaps).
Do the same for a 16 bit version of the same image.
Examine the areas where fine gradients of color are present.
You should see detail in the 24/32 bit, while not so much detail in the 16 bit.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@Cool_amigaN
I realise you are ANGRY, and therefore trying to have a rational debate with you may be fruitless. However I shall try:

Quote:

Rather kind way to express it. How about : The on board gfx of sam isn't ideal for modern resolutions?

I actually feel that I overstated how much of a problem it was. For 1280x1024 it is absolutely fine. And my calculations (below) suggest that it should also be fine for your 1680x1050x32bit. The real problem at high resolutions is OS4's implementation of Compositing.

Quote:

Quote: HOWEVER, if you turn Compositing off, then such a screen will only use 6.7MB of memory, meaning you can fit 9.5 such screens in it's 64MB of memory. Surely this should be enough for pretty much everyone? look at what you are saying here. Meassuring every MB of the gfx, on a modern computer, so we can save some for use for other applications?

Errr, you got COMPLETELY the wrong end of the stick, because you are angry. Since I do not own a 1680x1050 monitor, I had to do a calculation to check whether that resolution should cause problems. My conclusion was that it is very unlikely to cause problems (withOUT Compositing), because it can handle far more screens than you are likely to ever have open.

Quote:

From when a feature of an OS becomes problem? Compositing on or off will save you some MBs of the gfx, won't add up at the amount you allready have. 64 MBs are way too low and I can't believe we are arguing about that subject here.

64MB is *a lot* for gfx, especially Amiga. You would only need more for playing Half Life 2 or some such modern game that we will never have ported (and which Sam440 was never designed for anyway!).

I really have no idea why we are arguing such a daft point, except that you are angry. Please turn Compositing OFF, and be happy. With a bit of fiddling (I made a post on it somewhere) you can have Compositing on Workbench, but off for other screens - hopefully that would work fast (difficult to say without trying it).


As for your benchmark, I would not trust your results, given all the performance problems you have been having. Which is not to say that I expect Sam440 to do amazingly well at micro-benchmarks (Rigo certainly doesn't), but real-world performance is OK IMHO.

P.S. I hope you also read my earlier reply (at the bottom of the previous page) about speed of various apps you are using.

Last edited by ChrisH on 18-Feb-2009 at 09:38 AM.
Last edited by ChrisH on 18-Feb-2009 at 09:37 AM.
Last edited by ChrisH on 18-Feb-2009 at 09:36 AM.
Last edited by ChrisH on 18-Feb-2009 at 09:35 AM.
Last edited by ChrisH on 17-Feb-2009 at 08:08 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@A3000T

Quote:

I haven't met anyone yet who can tell the diference between a 16bit and 32bit screen by looking at it.

It's worth remembering that almost everyone who's using an LCD monitor with their SAM will only see 18-bit colour at best because that's all the monitor can show, even if the it's being given a 32-bit signal.

_________________
Who do you serve, and who do you trust? - Galen

@$adddam

The AMCC 440 is rather a G2 class cpu than a G3. Biggest drawback: no L2 cache. The ALU is also G2 class 2MIPS/MHz vs. 2.3 MIPS/MHz on a 750 (aka G3). But nevertheless it shouldn' feel much slower than a Peg1 G3/600 since the difference is not too huge, the RAM is faster and SATA is another plus.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@ChrisH

Quote:

My conclusion was that it is very unlikely to cause problems (withOUT Compositing), because it can handle far more screens than you are likely to ever have open.

Screens are not the only things which use VRAM.

@ChrisH

There's better chance for Wii level games.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@A3000T

Quote:

No. I haven't met anyone yet who can tell the diference between a 16bit and 32bit screen by looking at it.

16-bit images look bad to me. They have to be dithered to hide the colour banding, and that sucks. For most daily use 16-bit might be adequate, but if I'm looking at my photographs I want 24-bit colour.

When I buy an LCD monitor for my SAM (if it ever arrives - 99 days waiting so far) I'll get one that can do 24-bit colour, not one of those cheap 18-bit ones.

Maybe I'll stick with a CRT for a while, though.


Anyway, 64MB of video RAM sounds like more than enough for me. None of my Amigas has more than 2MB (GVP Spectrum) and my Amithlon box has only 4MB I think. Not sure I even know someone with 64MB VRAM in their box. But I don't consort with gamers anymore.

Last edited by robo-ant on 18-Feb-2009 at 02:21 PM.

@Georg Quote:

Screens are not the only things which use VRAM.

I'm sure you are right, my understanding of how this is implemented by AmigaOS is rather vague, but presumably screens are the main users of VRAM (when Compositing is disabled).

Last edited by ChrisH on 18-Feb-2009 at 06:12 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

I use 16-bit 1680x1050 on my µA1, which has only 32MB video memory, with compositing enabled without any problems. In addition to this I can also run Battle for Wesnoth on it's own screen also at 1680x1050 and I still do not have any problems with speed.

The SAM has twice the amount of video memory as the µA1 hence it should have no problems handling such resolutions.

@Cool_amigaN

Quote:

True, on 1680x1050x32bit Sam is completely unusable, leaving you from 4-15 MB GFX Ram only with only few drawers and OWB open. The situation turns out good only when using 16bit (e.g same resolution, with same amount of opened drawers and OWB tabs I get around 35-38MBs). But using 16bit instead of 32 in 2009 isn't really a progress, instead is a step bakwards, correct?

I don't know how you get "from 4 to 15 mb of GFX ram" by opening a few drawers and only OWB...
As you can see from the grab of my system (sam440ep@667mhz) I opened several windows (drawers) and OWB at 1680x1050x32bit with compositing enabled and I still have more than 23,5 MB of VideoMem available. The backdrop is a jpg of 1680x1050@32 bit, and I have Limpidclock running and a docky that display a slideshow (plus several other commodities but they are not influent on video mem, I think).


Lecta's Workbench

Last edited by Lecta on 18-Feb-2009 at 07:25 PM.

_________________
Stefano Guidetti
AmigaOS 4 Translator & Betatester

AmigaOneXE G4@1Ghz 2GB RAM Radeon 9000 PRO 128MB
Sam460ex@1,1GHz 2GB RAM Radeon X1550 PRO PCI-E
Both running AmigaOS 4.1 Update 6 (BETA)