Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Crusher on November 27, 2003, 02:44:15 AM
-
If you are, can you tell me everything you know about this card? :-)
-
@Crusher:
I am not a owner of the card, but I can tell you a bit I have read about it.
From a hardware point of view the card is constructed with more modern technology than the mediators. The only direct benefits from that is that the design is smaller, should draw less current and produce less heat.
From a software point of view the company - matay seems very open about releasing information. You will for example get software developer kit with your board and the Prometheus is supported by the OpenPCI library. Not like Elbox...
The only real drawback I can see with this card is that the physical fitting of the card and pci-cards on it might be a quite experimental experience if so to say ;).
/Patrik
-
Thanks for the answer, although I knew that already besides the thing that it has more modern tech. and you´ll get a SDK with it. That sounds great to me.
...and I think I like the OpenPCI attitude more and more know. :-)
-
Has there been any tests on CPU to VRAM memory with this one? What's the speed difference compared to a Mediator?
-
@Jose:
On the Prometheus homepage (http://www.matay.pl/matay/amiga_en/index.php?page=prom) they claim that real transferrates between the Amiga and PCI-cards can reach 12MB/Sec.
Isnt there anyone reading these forums with a Prometheus who can test the transferrates and post them here?
/Patrik
-
I got a Prometheus card... not in use though... still not come around to build my A4000 into a custom tower (which is nessesary to fit PCI cards).
Matay's info about Prometheus (http://www.matay.pl/index.php?id=prometheus&PHPSESSID=c7f892b6213b50a8cac28a58509e3b6b)
Prometheus drivers etc. (http://www.matay.pl/developer/en/index.html)
-
@Brian:
I must just add the Prometheus Developer Section (http://www.matay.pl/developer/en/developer.html) link which could be found in your last link. It explains quite thoroughly how the Prometheus functions, very interesting reading indeed.
/Patrik
-
@Brian:
What can I do to convince you to try the Prometheus with a graphics-card and then do a transferrate-test? :)
/Patrik
-
It's pretty slow, with a test called RTG from Trodas I got about 8.5 MB/s; you can compare game speed tests on http://amigaspeed.de.vu. But works well and w/o problems with Voodoo3.
-
@zipper:
Sounds like the speed you would get with a mediator.
/Patrik
-
Didnt Karlos make a program for measurement of transferspeed between the Amiga and the video-memory of a graphics-card which was used in a quite extensive test featuring quite some different PCI-buses. It would be interesting to see how the Prometheus would score with that program.
/Patrik
-
Wow, what a respons to this thread... more... I need MORE :-D
Oh and zipper, maybe the speed has something to do with which CPU you have? :-?
-
@patrik
It was actually a pair of tests.
1) To see how fast the card's VRAM can be written to (which is bandlimited by the bus speed)
2) To see how the performance of Warp3D varies with state/raster size
The purpose of these tests was to help locate principal bottlenecks in the Warp3D system and to help determine the impact of bus speed (how fast data can be fed to the GPU) versus CPU speed (how long rasterization setup takes).
The tests were 680x0 only, principally to avoid the effect of context switching in the benchmarking (also slower therefore easier to measure accurately). Both CPU versions of each driver are usually compiled from a common source, so observations for the 680x0 version often apply to PPC also.
To measure bus speed only, all you need is the pixeltest program. I'd be happy to pass it on to anybody wanting to try it out on their promethius...
-
I used to use Prometheus in a loaded towered A3000. I was very happy with the results using a Voodoo 3 and 10Mbit ethernet.
If I'm not mistaken there are new OpenPCI drivers available which expand the number of supported devices greatly.
-
@zipper:
What do you think about running Karlos pixeltest program on your Prometheus and post the results in this thread? :)
/Patrik
-
No problem; where's the test? Do look at amigaspeed.de.vu, where you can compare Mediator, G-Rex and Prometheus game speeds on Quake, QuakeII etc. With same GFX card and CPU the numbers don't differ too much, but G-rex is maybe the fastest, Prometheus slowest. Other factors seem to contribute to the results which are not analyzed.
-
@zipper:
Karlos said in his post that it was just to ask him about the program and he would send it over.
/Patrik
-
Karlos?
-
Hi,
Sorry - I was away infront of the idiot lantern for a bit. Send me an email (if you havent already done so) and I can mail it to you :-)
-
You didn`t read these tests too carefully, did you?
Quake1: Mediator is the slowest even though tests are being made on V4/V5 gfx card. G-rex is on top here, but gets beat by Prometheus here and there.
Quake2: Prometheus is the best. No Mediator tests here but G-rex and CVPPC gots beaten up smoothly
Heretic2: Slight difference between A4k version of Grex and Prometheus, Mediator is the slowest.
Payback: Funny thing, Grex is the slowest here, Mediator/Prometheus extactly the same.
In overal Mediator is worse in these tests than Grex 4000 and Prometheus.
-
Oh, btw.
From what I hear the current price from upgraded Prometheus is 170euro.
Is that right ComputerCity is upgrading older boards for free? I think they have that upgrading device.
-
zipper?
/Patrik
-
@liluh
Well, it all depends on actual the driver implementation under each system, bus speed alone is far from the deciding issue...
-edit-
PS : It seems I simply cannot spell Prometheus - I keep writing 'ius' on the end :lol:
-
Didn't work. I emailed to Karlos.
-
@zipper
My fault - I realised later that I emailed you an old version which is asking for v4 of cybergraphics...
Sorry dude :-(
On some p96 systems this worked and on others it didnt. In the end, the code only needs v43, but thats what happens when you just use the version macro that comes in your devkit ;-)
I will send you the updated version as soon as I get a chance...
-edit-
Incidentally, it did work, exiting cleanly because it failed to open v42 of cybergfx. That hideous negative returncode told me so ;-)
-edit2-
Working version should now be in your mail ;-)
-
OK, I'll be back ... after having finished today's job.
-
BTW, is the P96 emulation library responsible for that v41 of cybergraphics.library that pretends to be in my setup which is equipped with P96 graphics?
-
Yeah. Basically p96 allows applications to open the cybergraphics.library via its emulation.
I have found that for my needs (chunky 8/15/16/23/32 bit surfaces and direct VRAM access) that CGX is fine and that p96 emulation handles it all flawlessly...
My only mistake in the earlier version was using the macro that defines the cgx library version number. As I was using the 4.x devkit it asked for v42 minumum...
Later, I changed all my setup code (in my libraries) to ask for the proper minimum version of libraries they need...
-
OK, Prometheus tested. Here are the results for a PIV sitting in there coexisting with Voodoo3; Voodoo3 results were a little slower. Perhaps PIV is capturing some cycles?
Set : 4910289 pix/sec 9590.40 K/sec
Zero : 3235813 pix/sec 6319.94 K/sec
Copy : 4551111 pix/sec 8888.88 K/sec
Conv : 4542698 pix/sec 8872.45 K/sec
Conversion attained 99.81% copy speed
-
-edit- Sorted out which gfx card was which :-)
So
The PIV attained a set test of 9590.40 K/sec
The Voodoo3 (PCI) got 8458.14 K/sec
Both results were for locked 32-bit access to an offscreen, big-endian 16-bit RGB surface.
Time to run away before Patrik gets here :lol:
-
Set : 4910289 pix/sec 9590.40 K/sec Zero : 3235813 pix/sec 6319.94 K/sec Copy : 4551111 pix/sec 8888.88 K/sec Conv : 4542698 pix/sec 8872.45 K/sec Conversion attained 99.81% copy speed
...and you are talking about what? :-? :-)
-
Crusher wrote:
Set : 4910289 pix/sec 9590.40 K/sec Zero : 3235813 pix/sec 6319.94 K/sec Copy : 4551111 pix/sec 8888.88 K/sec Conv : 4542698 pix/sec 8872.45 K/sec Conversion attained 99.81% copy speed
...and you are talking about what? :-? :-)
The pixeltest program was originally designed to benchmark some graphics conversion routines I created compared to simple copy/clear/set, all of which can operate direct to VRAM and hence are limitied by the bus speed.
1) Set
The set test uses an 16x unrolled loop of
move.l d0, (a0)+
where d0 contains the value to write (which can be more than one pixel, but always 32-bit value)
This particular test is completely limited by the bus
2) Zero
The zero test uses a 16x unrolled loop of
clr.l (a0)+
which zeros the address. This was purely to see how clr.l (a0)+ would compare to move.l (a0)+ over different busses. So far, and unsurprsingly, the move.l is faster.
3) Copy
The copy test simply involves copying data from system ram to VRAM, using a 16x unrolled loop of
move.l (a1)+, (a0)+
It doesn't actually do any modulus compensation or anything (which is why the test can look odd on some window sizes), but it is designed to test how fast a realistic memory -> vram transfer takes.
4) Conversion
The conversion actually tests some conversion code I wrote. This code converts a rectangular block of pixels (complete with modulus) from the source (in system ram) to a rectangular block of pixels in VRAM, taking care of modulus.
There is actually a bug (not dangerous) in that conversion code, that doesnt update the row address properly for certian modulus values (from window widths that arent a multiple of 32), but its irrelavent to the bus speed estimation argument anyway. For the sizes chosen in the test, that bug is never encountered anyway.
The way the pixeltest program is invoked for this particular test, this conversion is basically a copy operation, since the source and destination formats are the same in both cases. The fact it isnt as fast as the copy test (3) is that it has to do row by row conversion and take care of modulus.
For the purposes of pure bus speed (no burstmode) estimation, the only value you need to look at is the set test.
Read on only if you are interested...
The pixeltest program is built upon my C++ portability framework and is designed to test some low level pixel conversion code provided by the platform specific back end. This is software on most systems (including amiga). Pixel formats vary from system to system, so my backend needs to be able to convert from whatever format the programmer is using to whatever format the system prefers for a given representation.
Normally, as a library user you'd just use either 8/15/16/24/32 bits (a)rgb, without caring about endian ness or rgb mapping. At the end of the day, if you write a block of pixels (usually stored in an ImageBuffer object) to a Surface object, the absolute conversion is performed for you. Imagine it works a bit like this:
ImageBuffer*myImage = ImageLoader::loadNew("test/image.ppm");
/*
We don't need to know what actual pixel format the image is, nor the surface.
We can enquire, or we could have used eg:
ImageLoader::loadNewImage(char* name, Pixel::Type format);
to enforce a given format.
*/
Surface* mySurface = myDisplay->getDrawSurface();
mySurface->putImageBuffer(myImage, xpos, ypos);
Things like pixel conversion are hidden from you, as is clipping in this case.
However, you can select 'absolute' formats, such as 'rgb16b', meaning 16-bits rgb (5:6:5), big endian representation, if you know what (ans why) you are doing.
Anyway, the pixeltest program is designed to test these 'invisible' conversion routines, so if you want to see the conversion code operate (and bug free :-) ), you need to run the program from a shell as follows
pixeltest width height fmt
where
is a multiple of 32, eg 320, 512, 640, 800 (minimum is 160, default is 160 IIRC)
is the height. Any value is OK (minimum is 120, default is 240)
is the source format. Should be one of the following absolute formats:
rgb15b
rgb15l
bgr15b
bgr15l
rgb16b
rgb16l
bgr16b
bgr16l
rgb24p
bgr24p
argb32b
argb32l ( aka brga )
abgr32b
abgr32l ( aka rgba )
In the above, the last letter indicates endian format, eg b = big, l = little. The 24-bit sources use 'p' indicating 3-byte packed.
The destination format is whatever format your workbench screen is using. You don't really have much say in that other than what your screenmode prefs lets you set. Note that 8 bit screen depths are not supported by this program.
When you invoke the program you will see some output such as (this for a argb32b source running on a 16-bit rgb desktop)
Test data pixel format
Bytes : 4, endian native
Bits : A[ 8] R[ 8] G[ 8] B[ 8]
Offsets : A[ 24] R[ 16] G[ 8] B[ 0]
Maxima : A[255] R[255] G[255] B[255]
Window pixel format
Bytes : 2, endian native
Bits : A[ 0] R[ 5] G[ 6] B[ 5]
Offsets : A[ 0] R[ 11] G[ 5] B[ 0]
Maxima : A[ 0] R[ 31] G[ 63] B[ 31]
Now, what you are seeing is a breakdown of source and destination formats:
Endian : native / swapped
Bits : number of bits for each channel
Offsets : offsets of bits within word
Maxima : maximum integer value for channel