@AMiGR

Does the Dragon have opcodes which are the same as 680x0 but have a different implementation?

Off course icon reading is slow ! The machine was reported to be playing a DVD...

Don't you know that anything eating some CPU dramatically slows down I/O on AmigaOS ?

Just try reading a big Video or a DVD and then open a drawer full of icons. Even on Pegasos it will be slow... the fact that icons reading is that slow doesn't prove anything...

Leo.

_________________
http://www.warpdesign.fr/

@AMiGR

Quote:

Those will have to be replaced and unless if they are replaced at run-time and NOT at load-time, self-modifying code will fail.

At load time, you also don't know which of the words you just loaded are code, and which are data. Unfortunately, the obvious solution ("start at the start, and for each branch, explore all possible targets") fails miserably the moment you hit the first jump table....

There is also a potential issue with "overlapping instructions", where the same bytes get used in different instructions, depending on where you enter a function. This was fairly popular in TRS80 derived Z80 machines... instead of having something like

entry1:   ld a,1
          jr common entry
entry2:   ld a,2
          jr common_entry
entry3:   ld a,3
          jr common_entry
entry4:   ld a,4

common_entry:    ; Do stuff with a

entry4:  ld a,4
         db 0x21
entry3:  ld a,3
         db 0x21
entry2:  ld a,2
         db 0x21
entry1:  ld a,1
common_entry:    ; Do stuff with a

@AMiGR

Quote:

Sure, if you totally offload everything elsewhere and only do the decoding itself, it might cope. Find me a player than is that optimised and we'll talk a

I like that myth, that a ppc is too slow to decode video. I'm curious where you get this info from. DvPlayer can easly play a video form HD while my OpenGL-SW-renderer renders 'ray' in 640x480 @ 11fps (even without video, the max fps is 13. And that low fps is based on the extensive ray tracing done in ray, not the pixel transfer). It's not the cpu (!), but the rest of the system. The CD-IDE transfer is way to slow to stream from DVD, so is the over all gfx sub system (which needs a total re-write - eventually). locks on every render cycle can eat up to 50% bandwidth, static buffers are not (really) possible (and even while gfx bandwith is slow, it would allow for 800x600x100fps still). No, the machine would be fast enough, but there is still potential to optimize (let alone HW support thru the gfx chip or other).

I have no idea what that would translate into Coldfire, but it's still 50% slower then the slowest ppc (except Blizzard/CS-PPC). If, however, it would scale linear, that would still be a nice speed (I im curious how efficient a CF JIT could translate 68K into. Does it matter what native ISA one uses ? e.g. more efficient if the target is similar to the 'source').

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Jorge

Quote:

I like that myth, that a ppc is too slow to decode video. I'm curious where you get this info from. DvPlayer can easly play a video form HD while my OpenGL-SW-renderer renders 'ray' in 640x480 @ 11fps (even without video, the max fps is 13. And that low fps is based on the extensive ray tracing done in ray, not the pixel transfer). It's not the cpu (!), but the rest of the system. The CD-IDE transfer is way to slow to stream from DVD, so is the over all gfx sub system (which needs a total re-write - eventually). locks on every render cycle can eat up to 50% bandwidth, static buffers are not (really) possible (and even while gfx bandwith is slow, it would allow for 800x600x100fps still). No, the machine would be fast enough, but there is still potential to optimize (let alone HW support thru the gfx chip or other).

I didn't say anything about it being too slow to decode *video*, I said that it's too slow to decode full resolution *DVDs*, which comes from my personal experience in trying to do so on a G3 at 600MHz. And what is your CPU? If it's a G4, no surprise there, really, Altivec owns for video stuff. Now, with a *proper* caching mechanism and ATA DMA, a G3 should have no problems decoding a DVD, but I was talking about a **400MHz** 603e (PPC440), which definitely is NOT fast enough for DVD decoding from disc, which explains why IBM has put an MPEG2 decoder on the STB version of the chip.

_________________

@COBRA

Yes, Piru has mentioned this quite a few times. For example:

"However - like pointed out by others - in addition asl, asr, mulu and muls instructions clear overflow (CCR[V]) flag, rather than setting it according to result like m68k. Execution of these instructions is different from m68k, without being able to trap the instructions. "

(source: http://www.ann.lu/comments2.cgi?view=1113818538&category=web#message27)

_________________

@AMiGR

Quote:

If it's a G4, no surprise there, really, Altivec owns for video stuff

Negative. 800MHz G3Fx (yes, I have it downclocked again). I should try this with a downclocked 300 or 400MHz cpu...

And, well, the SAM has a faster mem interface, and maybe faster vmem bandwith (PCI66, if this reaches the full bandwith will be about twice as fast as the A1).
And, well, guess what, the FPGA can be used as a copro which could at least assist the cpu in decoding (or could also allow to implement SIMD instructions - thru a 16bit 66MHz bus directly into the cpu). I still would like to see how fast the 440 can really be, seems a 5200 can decode full screen video...

As I said, for DVD playback I believe the bottleneck is the IDE transport from the DVD into mem which might trigger interrupts of what not and might eat up bandwitdh. It certainly is possible from HD. Thus, again, its the overall system, not just the cpu.


To bring that back to the Dragon. The AGP bus looks nice, though. I didn't follow up on the performance.
Does it run 68k SW/OS now or what's the big deal? Not quiete fast or what ? Does it need to emulate the 68k still ?

Last edited by Jorge on 14-Nov-2006 at 06:02 AM.

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Jorge

Quote:

And, well, the SAM has a faster mem interface, and maybe faster vmem bandwith (PCI66, if this reaches the full bandwith will be about twice as fast as the A1).

It has a faster memory controller and, according to Laire who has worked with 440s, an incredibly slow LOAD-STORE unit crippling it.

Quote:

And, well, guess what, the FPGA can be used as a copro which could at least assist the cpu in decoding (or could also allow to implement SIMD instructions - thru a 16bit 66MHz bus directly into the cpu). I still would like to see how fast the 440 can really be, seems a 5200 can decode full screen video...

Hang on a minute, if the FPGA is programmed to be used as a co-pro, it's not the processor that is doing the decoding, I'm talking about the 440 603e *core* here. "Decoding full screen video" is a *very* vague term that means nothing, full screen video can be uncompressed, can be a DVD decoding at half res, a DVD decoding at full res, it could be a high resolution DiVX (which most definitely will *not* be decoded on such a processor) or, worse, an h.264 (which slams a dual G5 at high resolutions). Yes, for DVDs, the CPU itself can cope with the decoding if it's the only thing it does (ie. reading from HD instead of DVD), as seen in the Efika videos using that processor. I think that the 5200 is also available at 667MHz, that should be much better for such purposes.

Quote:

To bring that back to the Dragon. The AGP bus looks nice, though. I didn't follow up on the performance. Does it run 68k SW/OS now or what's the big deal? Not quiete fast or what ? Does it need to emulate the 68k still ?

It does... Emulated. According to people there, it was either a big faster than a 040 or a bit slower, depending on who you believe. Too bloody slow to be useful, if you ask me, most applications will never be recompiled for ColdFire. Now, if Elbox could implement a full JiT, it'd make it faster but why would you use that instead of a PPC, then?

_________________

@AMiGR

Quote:

I think that the 5200 is also available at 667MHz, that should be much better for such purposes.

No at all, according to Freescale, 5200 is available max @ 400 Mhz

http://www.freescale.com/files/32bit/doc/data_sheet/MPC5200.pdf?srch=1

_________________
Massimiliano Tretene, ACube Systems, Soft3

@AMiGR

Quote:

t does... Emulated. According to people there, it was either a big faster than a 040 or a bit slower, depending on who you believe. Too bloody slow to be useful, if you ask me, most applications will never be recompiled for ColdFire. Now, if Elbox could implement a full JiT, it'd make it faster but why would you use that instead of a PPC, then?

I actually don't understand why they are doing this. Maybe the were badly informed, when they started the project and did hope they could run some 68K code natively.
The very same could have been achieved thru a PPC (actually it would be faster no matter what). It amazes me again and again, how companies neglect the fact, that R&D costs are part of the resulting product (e.g. having a programmer sitting around for one year to figure out how to get that thing working should not really be cheaper then say paying for an OS4 license).

Do they use a QuickPAK interface (or what's that called ?). In that case the CPU could theoretically be swapped against a PPC board. Hopefully they realize that.

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@AMiGR

Quote:

Yes, for DVDs, the CPU itself can cope with the decoding if it's the only thing it does

This is not the primary point here. While, sure, you are right, the more cpu time the decoder gets, the more it can do. But it is embedded into the whole system. E.g. if the bitmap lock eats up 50% of the time and the cpu is just waiting until it can decode the next frame, it is highly inefficient. These are the limits of the current system not the cpu.
If your statement is correct, that the cpu is fast enough to decode the stream, then it is obviously the overhead of the rest of the system which causes the delay. No matter how fast the CPU is, this will always be a problem (but sure, if your gaps are small, a faster cpu can do a lot more in the small gaps).

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@AMiGR

Quote:

I think that the 5200 is also available at 667MHz, that should be much better for such purposes.

The MPC5200@400MHz is rated at 760 Dhrystone MIPS, while the 440EP@667MHz is 1334 Dhrystone MIPS. IF an MPC5200 was ever available at 667MHz (on Freescale's website it's listed at 400MHz max), it would not be any faster than a 440EP at the same clock speed.

Last edited by COBRA on 14-Nov-2006 at 04:04 PM.
Last edited by COBRA on 14-Nov-2006 at 04:00 PM.

@COBRA

Sorry, I got confused, I meant the 440EP. Whenever I'm talking about the speed of the 440, I always mean the 400MHz version, just like the 5200.

Last edited by AMiGR on 14-Nov-2006 at 04:18 PM.

_________________

@AMiGR

Quote:

I didn't say anything about it being too slow to decode *video*, I said that it's too slow to decode full resolution *DVDs*, which comes from my personal experience in trying to do so on a G3 at 600MHz

An AmigaOne-SE 600 Mhz is able to play a DivX full screen move, whit MPlayer, I know because Antique has one, but I don’t think I ever exchange my AmigaOne-XE-G4 866 Mhz whit his, the 600 Mhz G3 is able to play the DivX thanks tanks to frame skipping I think.

Any thing under that is will require a hardware video decoder chip of some kind, or simply smaller resolution on the movies.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Jorge

Quote:

This is not the primary point here. While, sure, you are right, the more cpu time the decoder gets, the more it can do. But it is embedded into the whole system. E.g. if the bitmap lock eats up 50% of the time and the cpu is just waiting until it can decode the next frame, it is highly inefficient. These are the limits of the current system not the cpu. If your statement is correct, that the cpu is fast enough to decode the stream, then it is obviously the overhead of the rest of the system which causes the delay. No matter how fast the CPU is, this will always be a problem (but sure, if your gaps are small, a faster cpu can do a lot more in the small gaps).

Well, for example, in MorphOS, there are no bitmap locks for video decoding, there is overlay in the drivers. At the same time, a 600MHz 750CXe struggles to decode a DVD using MPlayer. It should be able to with a proper caching mechanism in the player, though.

_________________

@AMiGR

With DvPlayer I'm now down to 70% CPU usage on G3/800Mhz (using overlay), which means a G3/600 would still handle that without problems. I hope to improve on this still.

@COBRA

It would be interessting to see where the bottle neck is, exactly (e.g. with a profiler). Can you benchmark the decoder separately ?

BTW: Overlay does not resolve the problem of the locks, it just reduces the needed memory bandwidth (e.g. a 16bit YUV stream instead of letting the cpu convert YUV into some RGBish format (does not really matter if 16 or 32 bit, 16bit saves a lot of bandwith, but still, one has to convert YUV into 16bit RGB while overlay usually allows a plain transfer into the "window" without any converter).

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Leo

Off course icon reading is slow ! The machine was reported to be playing a DVD...

You mean this ?

_________________
~
Everything you say will be misquoted and used against you..
~

@Seer
Quote:

Seer wrote: @Leo Off course icon reading is slow ! The machine was reported to be playing a DVD... You mean this ?

Maybe they just didn't have IconBeFast installed on their OS 3.9 installation. Makes a huge difference!

If the Dragon ever DOES come out and it has a bypass option, unlike the ACK classic board, then I would consider getting it for my 4000T so I could put AOS4 on it, assuming of course AOS4 final for the classic ever DOES come out!

_________________
When swimming with sharks, make sure to bring lots of band-aids...