Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Motormouth on April 01, 2017, 01:32:44 AM
-
I notice that many people are using RTG video cards with vampire 500 .
Why, is the video slow, refresh issues? etc.
How fast is the vampire video vs RTG cards.
I guess it is possible to make a direct comparison with picasso II and some of the zorro III cards that have zorro II modes. Anyone attempt this?
How about indirect comparisons? ie voodoo ati zorro III modes of picasso IV, cybergraphx, permedia based card, etc.
-
Here is an Apollo forum thread from 2015 showing P96Speed results for 640x480 and 800x600. Note that these are for a very old version of the core and are likely faster now.
According to a poster on that thread the Vampire was 2x the speed of a CV64 except for rectfillpattern.
http://apollo-core.com/knowledge.php?b=2¬e=133&z=5vTxib
-
I notice that many people are using RTG video cards with vampire 500 .
Why, is the video slow, refresh issues?
I would believe this is because many graphic cards come with an on-board blitter which helps accelarating a couple of graphics operations. AFAIK, the vampire is a frame buffer only, or has only limited capabilities as far as blitter support is concerned.
-
im not sure it this is still the case but initial implementation or rtg on vampire was likely simple framebuffer, without any accel laike blitter, as thomas says. now it might be they have implemented some accelerated memory copy functionality into the core, maybe even masked and such, but i dont know it.
another issue is that vampire shares the same bus to memory for cpu and rtg, so it can starve with higher resolutions and frequencies, while cpu is doing much memory access. the solution to this is as far as im aware a lower rtg frequency, as long as the hdmi display device supports it.
-
I would believe this is because many graphic cards come with an on-board blitter which helps accelarating a couple of graphics operations. AFAIK, the vampire is a frame buffer only, or has only limited capabilities as far as blitter support is concerned.
im not sure it this is still the case but initial implementation or rtg on vampire was likely simple framebuffer, without any accel laike blitter, as thomas says. now it might be they have implemented some accelerated memory copy functionality into the core, maybe even masked and such, but i dont know it.
another issue is that vampire shares the same bus to memory for cpu and rtg, so it can starve with higher resolutions and frequencies, while cpu is doing much memory access. the solution to this is as far as im aware a lower rtg frequency, as long as the hdmi display device supports it.
This is quite interesting and helpful. I wonder if blitter could be implemented in the FPGA, this would required programing of a specific video chip, which would be tricky or a custom video chip in FPGA which would require its own, albeit virtual, VLSI layout and new picasso96 driver.
It looks like Complete testing of different video solutions would require not only comparisons of different resolution, but also effect on CPU speed and memory transfer speeds.
-
The ultimate is to use FPGA based gfx card, like the mnt va2000, along with vampire :)
-
Here is an Apollo forum thread from 2015 showing P96Speed results for 640x480 and 800x600. Note that these are for a very old version of the core and are likely faster now.
According to a poster on that thread the Vampire was 2x the speed of a CV64 except for rectfillpattern.
http://apollo-core.com/knowledge.php?b=2¬e=133&z=5vTxib
This is probably more than fast enough for most applications.
-
The ultimate is to use FPGA based gfx card, like the mnt va2000, along with vampire :)
Interesting, I didn't even know that this mnt va2000 existed. The cost is high, but then again this is an expensive hobby.
-
The ultimate is to use FPGA based gfx card, like the mnt va2000, along with vampire :)
Actually, the VA2000 has pretty much the same problem as the vampire, namely having a considerably incomplete blitter that provides relatively poor speedups with graphics, or only in relatively rare cases. In terms of speed graphics cards based on dedicated (legacy) chips like the Cirrus series are still preferable, e.g. Matze's graphics card just works fine.
This being said, the FPGA solutions have a higher potential, but it will still take a while for them to catch up.
-
Interesting, I didn't even know that this mnt va2000 existed. The cost is high, but then again this is an expensive hobby.
Yes, it is. My comment was not meant to be taken too seriously, it's just the aspect of filling the Amiga with FPGAs that I find funny :)
-
Yes, it is. My comment was not meant to be taken too seriously, it's just the aspect of filling the Amiga with FPGAs that I find funny :)
Yes, and then we replace the Amiga itself with an FPGA board...
It IS getting a little weird.
-
Yes, it is. My comment was not meant to be taken too seriously, it's just the aspect of filling the Amiga with FPGAs that I find funny :)
Actually I find FPGA interesting. In some ways they are emulation and in some ways they are actual hardware.
-
The ultimate is to use FPGA based gfx card, like the mnt va2000, along with vampire :)
actually it is better to use local rtg on the same fpga (which vampire already provides, as much as va2000) rather than behind (by todays standards) slow bus.
-
Yes, and then we replace the Amiga itself with an FPGA board...
It IS getting a little weird.
why? to each his own. while i d like to have an fpga expansion for my amiga (i dont have one) others may favor a new stadalone compatible system.
what it boils down to is to hold to most sommon denominator as closely as possible to be able to address and serve the widest fraction of audience, which is the suers of the genuine amiga (68k) software.
-
Actually I find FPGA interesting. In some ways they are emulation and in some ways they are actual hardware.
Nobody said they weren't interesting, i just feel like I'm "cheating" when I use hardware based on one. Like its not "real" hardware.
But the results are fascinating, and as I mentioned before when discussing ISAs, its really about what runs your software well.
-
Nobody said they weren't interesting, i just feel like I'm "cheating" when I use hardware based on one. Like its not "real" hardware.
But the results are fascinating, and as I mentioned before when discussing ISAs, its really about what runs your software well.
@Iggy I did not mean any disrespect and you have a a great point!!! I think I am just anxious to get any new hardware after all these years.
-
@Iggy I did not mean any disrespect and you have a a great point!!! I think I am just anxious to get any new hardware after all these years.
No, no, I didn't take that at all that way.
I might buy one of the Vampire accelerators myself (and I have other fpga hardware), IF I'm "allowed" to obtain one via their weird marketing scheme.
Its just that real '020, '030, '040 & '060 based accelerators feel more "authentic" to me.
After all, I could have bought components like that when Amigas were still current.
Then again PC
I expansion boards and Radeon 9200 video cards aren't that authentic either.
And I'm not sure whether I want a ZorroII video card for my A2000 or not.
ZorroII transfer rates are incredibly slow.
-
blah blah blah..
-
blah blah blah..
byte me ;-)
-
That's something I'd never considered before,.... the shared RAM bandwidth for "CPU" and video/rtg. Its no wonder benchmarks on the forum are restricted to 640*480 and 800*600.... they'd give better performance. The higher the resolution the slower both graphics and "CPU" will perform.
-
@Iggy
I think its somewhere between "real" thing and minimig, closer to real.
however its so fast, and lets you keep the case... so its obviously very desirable.
I'd just wait a bit longer, the production will surely go up.
-
byte me ;-)
;D
-
That's something I'd never considered before,.... the shared RAM bandwidth for "CPU" and video/rtg. Its no wonder benchmarks on the forum are restricted to 640*480 and 800*600.... they'd give better performance. The higher the resolution the slower both graphics and "CPU" will perform.
yes, i think this is the reason. might be considered a hardware flaw and maybe to be corrected in future implementations. likely there is pros and contras using unified versus separate ram for main memory and rtg.
-
I'd imagine the pixel clock speed of cards like the cv64, PIV, CV64/3d and CVPPC can drive higher res screens.
i'm running 800x600x24@60hz on my vampire, and can probably push it to 1280x720, but to run "fullHD" 1920x1080, i would need to drop the freq to 24hz. something i probably wouldn't have to do with a "proper" card. and something i just can't be bothered to muck about with.
the vampire's "graphics memory" is a software assignable lump of shared space out the 128meg available on the Vampire - and the clock is based on the speed of the FPGA.
having said that, the vampire's 800x600 screen feels nice and smooth. smooth icon scrolling, smooth window movement. its just a nice place to be. no figuring out switching superlayers, or supergels on or off, or smart/simple window drawing. it just does it.
the CVPPC can ramp up to 230mhz@8bit on the pixel clock, and has 800Mb/s to its local ram. about twice the vampire's clock, and about 5 times the ~150-160Mb/s ram bandwidth that the Vampire has.
not to mention hardware blitter, and other stuff built in, or sharing the ram bandwith with cpu fastram operations.
i did find find the maximum assignable bitmap area on a Permedia2 chip is 2000x2000. annoying when trying to run a three screen setup via a Matrox Triple-head-to-go box. was amusing seeing a guru meditation error spread over three screens
anyway, just my experience.
640x480x24@60=52.734375 Mb/s
800x600x24@60=82.39746094 Mb/s
1280x720x24@60=158.203125 Mb/s
1920x1080x24@24=142.3828125 Mb/s
-
@darksun9210
It is interesting to hear your actual experiences with the vampire.
-
when i have a bit of time, i'll try to do a comparison between my BvPPC, CV64-3D and vampire, and hopefully shed a bit of light where each tops out, and why etc. etc. :)
i think a massive thing for having rtg on a vampire is the ability to run chunky mode screens for things like 3d shooters, Scumm, and mac/pc emulators with no c2p slowdown.
-
when i have a bit of time, i'll try to do a comparison between my BvPPC, CV64-3D and vampire, and hopefully shed a bit of light where each tops out, and why etc. etc. :)
i think a massive thing for having rtg on a vampire is the ability to run chunky mode screens for things like 3d shooters, Scumm, and mac/pc emulators with no c2p slowdown.
I am looking forward to your review/comparison.
I always find enthusiasm overruns Apollo core users like a religious sect. So they tend to publish benchmarks that specifically favour their agenda or corner cases where they can show off.
I believe you are one of the first ones I see that dont belong to that group. I will love to see the pros a cons of the SAGA rtg implementation.
-
I love reading about and watching the YouTube videos showing the Vampire but I will never own one for the same reason I don't emulate - I am only interested in the nostalgia and admiring the engineering and software for the time. Only places I do cheat is replacing capacitors (or else the computer will eat itself) and a PCMCIA CF adapter (copying stuff from the aminet using parnet or floppies is one headache I can do without).
Edit: Oh and an SSD HDD. lol
-
I am looking forward to your review/comparison.
I always find enthusiasm overruns Apollo core users like a religious sect. So they tend to publish benchmarks that specifically favour their agenda or corner cases where they can show off.
This reminds me of the Amiga vs Atari ST benchmarking, or for that matter any benchmarking Thunderbird vs. Pentium III, NVIDIA vs ATI, etc..........
I also like darksun9210's post. It is an honest look. I discusses both the advantages and disadvantages of the product.
-
I have an A500+ with an vampire.
Can run all the tests you want to see.
Link to programs and what to test and i'll post the results here.
-
http://www.a1k.org/forum/showthread.php?p=1060473#post1060473
-
http://www.a1k.org/forum/showthread.php?p=1060473#post1060473
Mein Deutsch ist nicht mehr gut
Luckily Google translate works very well, and yes this article is useful.
I have an A500+ with an vampire.
Can run all the tests you want to see.
Link to programs and what to test and i'll post the results here.
If you are willing it would be interesting to see how higher and higher video resolution *depth * rate effect cpu and memory performance.
I guess the easilest would be to use at least 4 resolutions @ the same 24 bit at a fast frame rate. A control would be the same parameters only using a RTG card.
-
Mein Deutsch ist nicht mehr gut
Luckily Google translate works very well, and yes this article is useful.
If you are willing it would be interesting to see how higher and higher video resolution *depth * rate effect cpu and memory performance.
I guess the easilest would be to use at least 4 resolutions @ the same 24 bit at a fast frame rate. A control would be the same parameters only using a RTG card.
Sure can test that tonight when i get home from work.
What CPU test bench do you prefer?
-
I am looking forward to your review/comparison.
I always find enthusiasm overruns Apollo core users like a religious sect. So they tend to publish benchmarks that specifically favour their agenda or corner cases where they can show off.
I believe you are one of the first ones I see that dont belong to that group. I will love to see the pros a cons of the SAGA rtg implementation.
Well this is not my feeling, about sysinfo scores and such yes i agree, that said about videos from some users, i think they just shares what they experiments, with some enthousiasm yes (too much ? maybe, but certainly not sectarism) but hey this board is enthousiastic when you have one.
-
Since the RTG drivers are not optimized for AMMX, it may be a bit premature to do speed benchmarks but the display DMA should be nearly finished in Gold 3.
-
P96Speed results on my x11 GOLD2 core. Vampire 500 v2
Test length 10 sec.
640x480x24 bit 60Hz
.============= SPEEDRESULTS ==============.
| RectFill()................ 1148 op/s |
| RectFill() Pattern........ 264 op/s |
| WritePixel().............. 216859 op/s |
| WriteChunkyPixels()....... 463 op/s |
| WritePixelArray8()........ 465 op/s |
| WritePixelLine8()......... 20536 op/s |
| DrawEllipse()............. 21808 op/s |
| DrawCircle().............. 22139 op/s |
| Draw().................... 9763 op/s |
| Draw() Hor/Ver............ 17894 op/s |
| ScrollRaster() X.......... 64 op/s |
| ScrollRaster() Y.......... 61 op/s |
| PutText()................. 3533 op/s |
| BlitBitMap().............. 3702 op/s |
| BlitBitMapRastPort()...... 3371 op/s |
| BitMapScale()............. 328 op/s |
|--------------- Intuition ---------------|
| OpenWindow().............. 170 op/s |
| MoveWindow().............. 298 op/s |
| SizeWindow().............. 207 op/s |
| CON-Output................ 161 op/s |
| ScreenToFront()........... 60 op/s |
`========================================='
800x600x24 bit 60Hz
.============= SPEEDRESULTS ==============.
| RectFill()................ 609 op/s |
| RectFill() Pattern........ 180 op/s |
| WritePixel().............. 207201 op/s |
| WriteChunkyPixels()....... 464 op/s |
| WritePixelArray8()........ 463 op/s |
| WritePixelLine8()......... 20232 op/s |
| DrawEllipse()............. 19378 op/s |
| DrawCircle().............. 19844 op/s |
| Draw().................... 7957 op/s |
| Draw() Hor/Ver............ 15396 op/s |
| ScrollRaster() X.......... 34 op/s |
| ScrollRaster() Y.......... 32 op/s |
| PutText()................. 3509 op/s |
| BlitBitMap().............. 3080 op/s |
| BlitBitMapRastPort()...... 2792 op/s |
| BitMapScale()............. 332 op/s |
|--------------- Intuition ---------------|
| OpenWindow().............. 159 op/s |
| MoveWindow().............. 312 op/s |
| SizeWindow().............. 187 op/s |
| CON-Output................ 120 op/s |
| ScreenToFront()........... 20 op/s |
`========================================='
1024x768x24 bit 60Hz
.============= SPEEDRESULTS ==============.
| RectFill()................ 303 op/s |
| RectFill() Pattern........ 105 op/s |
| WritePixel().............. 200851 op/s |
| WriteChunkyPixels()....... 459 op/s |
| WritePixelArray8()........ 459 op/s |
| WritePixelLine8()......... 20198 op/s |
| DrawEllipse()............. 16899 op/s |
| DrawCircle().............. 17454 op/s |
| Draw().................... 5992 op/s |
| Draw() Hor/Ver............ 12011 op/s |
| ScrollRaster() X.......... 16 op/s |
| ScrollRaster() Y.......... 15 op/s |
| PutText()................. 3500 op/s |
| BlitBitMap().............. 2498 op/s |
| BlitBitMapRastPort()...... 2274 op/s |
| BitMapScale()............. 330 op/s |
|--------------- Intuition ---------------|
| OpenWindow().............. 143 op/s |
| MoveWindow().............. 208 op/s |
| SizeWindow().............. 161 op/s |
| CON-Output................ 94 op/s |
| ScreenToFront()........... 10 op/s |
`========================================='
1280x800x24 bit 50Hz
.============= SPEEDRESULTS ==============.
| RectFill()................ 172 op/s |
| RectFill() Pattern........ 84 op/s |
| WritePixel().............. 173006 op/s |
| WriteChunkyPixels()....... 426 op/s |
| WritePixelArray8()........ 425 op/s |
| WritePixelLine8()......... 18567 op/s |
| DrawEllipse()............. 14000 op/s |
| DrawCircle().............. 14570 op/s |
| Draw().................... 4190 op/s |
| Draw() Hor/Ver............ 8987 op/s |
| ScrollRaster() X.......... 10 op/s |
| ScrollRaster() Y.......... 9 op/s |
| PutText()................. 3386 op/s |
| BlitBitMap().............. 1962 op/s |
| BlitBitMapRastPort()...... 1776 op/s |
| BitMapScale()............. 326 op/s |
|--------------- Intuition ---------------|
| OpenWindow().............. 121 op/s |
| MoveWindow().............. 226 op/s |
| SizeWindow().............. 126 op/s |
| CON-Output................ 90 op/s |
| ScreenToFront()........... 6 op/s |
`========================================='
Picture grabbed from SysSpeed v2.6 running at different resolutions on my WB.
Missed part of the benchmark when grabbing 640x480.
(http://i65.tinypic.com/13yfrx1.png)
-
awesome work. hope to get my benches up here shortly :)
-
@Nickman
Thanks for the post.
It is interesting that drive performance decreases whilst resolution increases. So drive and also cpu performance is reduced when resolutions increase.
It would be good to know what other subsystems are affected (ram, io, etc.) and up to which extent (percentage of reduction).
-
@Nickman
I agree with Gulliver and Darksun9210
This is quite useful!!!!!! I wonder how other video card will compare with increasing resolution. They will also have some penalty, but I image it won't be as much.
But let us put this in perspective even a "slow" vampire is still amazingly fast.....
-
Since the RTG drivers are not optimized for AMMX, it may be a bit premature to do speed benchmarks but the display DMA should be nearly finished in Gold 3.
@SamuraiCrow DMA will help. I have been impressed with the speed increases with etch new core Apollo has released.
-
(http://i63.tinypic.com/33dbi4x.png)
-
There must be a copy/paste error on DrawEllipse 1280.
All are 24bits scores ?
-
There must be a copy/paste error on DrawEllipse 1280.
All are 24bits scores ?
Of Course you are right. DOH!
All the results is on the previous page.. Had some time off at work today over lunch so i played with Excel :P
Typed all figures manually so missed a 0.
Updated the post with new image.
-
When i saw those results posted earlier i got curious how memory speed would be without saga running at all...
Some explanations on results you see here.
v500+ pal2: saga monitor driver is not in devs/monitors, and running pal640x256x4 when testing.
v500+ pal1: saga monitor driver is loaded from devs/monitors, but the resolution is switched to pal640x256x4 before running the test.
you: this is test is run with the screen resolution you see in the screenmode prefs window on the screen. This is the same saga resoultion used in v500+pal1 test, so switching to no-saga resolutions seems to have the saga-core running in the background when not used.
running v500+ gold core 2, and i believe x11 speed.
cheers! :)
(http://i65.tinypic.com/2whh7ib.jpg)
-
When i saw those results posted earlier i got curious how memory speed would be without saga running at all...
Some explanations on results you see here.
v500+ pal2: saga monitor driver is not in devs/monitors, and running pal640x256x4 when testing.
v500+ pal1: saga monitor driver is loaded from devs/monitors, but the resolution is switched to pal640x256x4 before running the test.
you: this is test is run with the screen resolution you see in the screenmode prefs window on the screen. This is the same saga resoultion used in v500+pal1 test, so switching to no-saga resolutions seems to have the saga-core running in the background when not used.
running v500+ gold core 2, and i believe x11 speed.
cheers! :)
(http://i65.tinypic.com/2whh7ib.jpg)
To get full speed when using the chipset, you need to use a special command to deactivate the HDMI output. The trouble is, I don't remember the custom command. It is one that was created by the team.
-
To get full speed when using the chipset, you need to use a special command to deactivate the HDMI output. The trouble is, I don't remember the custom command. It is one that was created by the team.
http://wiki.apollo-accelerators.com/doku.php/sagasleep
-
http://wiki.apollo-accelerators.com/doku.php/sagasleep
That's the one! Thanks ShK!
-
yes, i think this is the reason. might be considered a hardware flaw and maybe to be corrected in future implementations. likely there is pros and contras using unified versus separate ram for main memory and rtg.
I doubt they'll ever change it. The Amiga has always been designed around unified memory.
-
So how about speeding up the video clock , putting 1GB of memory on the card and let Saga have whatever it needs?
-
So how about speeding up the video clock , putting 1GB of memory on the card and let Saga have whatever it needs?
Making the ram bus wider might help, but there may be issues with doing that (including cost).
I thought they were at the clock speed limit for the FPGA already.
-
I read that the new board design was to allow higher clock. We'll see if it works.
-
I read that the new board design was to allow higher clock. We'll see if it works.
The newer board design is likely to use a newer FPGA. For example, a Cyclone 5 supports DDR3 memory while current designs use a Cyclone 3 with SDRAM.
-
I read that the new board design was to allow higher clock. We'll see if it works.
The newer board design is likely to use a newer FPGA. For example, a Cyclone 5 supports DDR3 memory while current designs use a Cyclone 3 with SDRAM.
Which Vampire board design are you referring to? Vampire 500 V2 to Vampire 500 V2+? Other?
-
Which Vampire board design are you referring to? Vampire 500 V2 to Vampire 500 V2+? Other?
Stand alone Vampire to V500+/V600.