Er, pardon my ignorance, but what exactly is missing?
far from it. you could have an ultra cheap laptop without using a mobile gfx chipset and if you want a better/more expensive you could use a mobile pci-x gfx card. or even better -though i don't know if that's possible anymore- you could provide the gfx card as a plugin card -i saw some vaios that have pretty much everything as add-on cards- so in theory some poweruser/oem might replace the parts he wants.

Konstantinos

PS. the problem is that right now there is no mid-range PowerPC system. Just low-end(EFIKA, SAM440, etc) and high-end (POWER) just won't do on their own. Unless someone builds one soon (the tetrapower or the 8641D were nice ideas), pretty soon, low- and high-end are the only places one will use PowerPC at all. Esp. considering the rapid advances of Intel and other arches (even Niagara kicks ass right now).

From the 8610?

Disk controller and ethernet for a start. USB.. a real audio controller too (AC97 still needs a codec on the end).
8610 is single core, low-GHz G4, how is it going to beat Niagara?

I agree an 8610 system would be pretty damn neat, there is definitely an opportunity for a low end 8610 system (on par with a PowerBook, definitely laptop-suitable) and a high end 8641D (perhaps a desktop workstation), but they would be pretty dull compared to the latest Intel or AMD offerings, and certainly not multithreaded server-class things like Niagara.

The time for the next generation Power Architecture desktop with 'high performance' is over before it begins if there are no chips to fulfil that market segment.

_________________
Matt Sealey

Leaving out Ethernet is quite strange especially when they mention
that it is a design derived from PowerQUICC. All in all it seems more
like they forgot some compounds or like selfcastration (I guess both
things are unlikely, but it really seems like that). I mean they
(=Freesacle) know pretty well what is needed for a full design and
they have the knowledge for real full SoC designs.
Why on earth do they such a half-design then? Even for the
broschure mentioned usages the lack of at least usb and ethernet is
not really an advantage...



Oh yes, especially a small energy efficient e600 system with MOS would
just fly. Sometimes it is really sad to see, that nice technologies
are not finding their way to the market. But we have the Efika at
least which is a neat piece of technology.

Maybe it is worthwile to look closer to SUN for more power...

Here is a video on youtube to watch working MPC8610 with Fedora core 6.

http://jp.youtube.com/watch?v=SZDusxG13QQ

And maybe some more. But nothing 64-bit and nothing with quad gigabit ethernet, or 3GHz speeds :D
If you need to run a server or do bioscience, then there are plenty of options on the market. IBM use 800MHz processors in BlueGene/L - so it's not like you can't get the job done on a 32-bit, low-GHz processor. You just need *LOTS* of them.
Impressive video, and probably a good showcase of what just the chip alone can do. Imagine how much better it could be with a more recent SuSE or Fedora.. certainly a very capable desktop machine, or a SOHO server.

Thanks for showing Power Developer :D

_________________
Matt Sealey

Another video has come.

http://www.youtube.com/watch?v=5BT1299hgI0

That is great, thanks. The more new hardware in the market, the better.

R&B :)

_________________
http://bbrv.blogspot.com

The MPC8610 evaluation board playing a high definition (1080p) DivX video?
It HAS to be a fake. Technical reasons upon request. I've received lots of them, but would need translation.

My estimation is that it gets pretty narrow for 1080p. Maybe the mem controller and Altivec are really that good.
Also note that the file was not h264, but DivX and 30fps. A fluent replay of 30fps 1080x1920 is within my estimation for 1GHz Altivec.
This is ~62,2 Mpx/s, the mem controller has to fetch about ~8MB/s of coded data and push forward about ~200 MB/s to the video/sound card. If dma is good then getting and pushing forward the data is at virtually no cpu cost.
60fps probably will be too much, though.
But I'd like to see some quantified benchmark.

There's no technical reason why it CAN'T be done, except if you are reading the Freescale website and making broad assumptions.

Wait, didn't I already tell you about this? :D

_________________
Matt Sealey

Here are some excerpts of technical reasons, courtesy of my source, my brother Fernando Marcos ("fmarcos@datavoice.es"):
Granted, but keep in mind that H.264, DivX, XviD and Windows Media are ALL about implementations around the MPEG4 format (with more or less features depending on the profile selected). All of them require roughly the same amount of computing power.
Please, keep in mind that even video can be encoded at 30fps, the screen must be driven at 50-60fps. That means pumping 2,07 megapixels per frame, or about 103 megapixels per second (at 50fps). At 24 bit per pixel, that means the LCD controller stealing 300 Mbytes per second memory bandwidth from the processor. Assuming that no video card is used (as it seems from the video), the color conversion alone would require almost every single CPU cycle left (MPEG4 video is encoded in YUV, while the screen must be feed in RGB). That would imply reading 200 Mbytes (16 bit YUV) information and generate 300 Mbytes per second RGB information BY THE
PROCESSOR itself. That memory would be "later" read by the LCD controller to feed the screen. Let alone MPEG4 decoding, of course.

And these are the original reasons:

Point 1: I'm sorry. I can't believe it. At 1Ghz, even with hand optimized machine code, there's not enough to decompress MPEG4 at 1080p.

Point 2: Has DivX developed an specific PowerPC optimized codec? Or is it generic platform independant source code?

Point 3: As it seems, connection to TV comes from a DVI port from the evaluation board, but on TV it reads "HDMI-2". Does not fit. HDMI is one thing, DVI another. Is there HDMI logic in the evaluation board?
Edit: I've just checked that it IS possible to connect DVI to HDMI (http://www.hometheaterhifi.com/volume_1 ... -2004.html).

Point 4: Directly obtained from the freescale page: "Integrated Display Controller supports up to SXGA 1280 x 1024 resolution and 24 bits per pixel". In theory, "1080p" is 1920x1080. That means that the image we are looking at is beyond the limits of the LCD controller.

Point 5: It they are really using the internal LCD controller of the SoC (which I doubt), have you calculated the bandwidth required to ONLY read the blocks from RAM? Just remember, 2 million pixels have to be written to screen, at 50/60 FPS. Assuming 16 BPP (not dreaming about 24), it comes at (being nice and assuming 1080p 50 FPS):

2 mpixels x 50 fps = 100 milion píxels per second.
100 mpixels x 2 bytes = 200 Mbytes/s.

If the LCD controller is not reading YUV directly from memory (if it supports it, of course), only the colour space conversion YUV-RGB would eat up the processor. What's more, I'd like to know what kind of memory does the evaluation board have. From freescale's web, the CPU supports upto DDR2 at 533 Mhz. The evaluation board has that type of memory? I suppose it has been fitted with "ordinary" memory (DDR2-533, operating at 133MHz), mostly because if they put "top" (DDR2-1066, operating at 533MHz), the evaluation board gets to 1000 dollars! He he he...

Assuming the LCD controller does 32 bit accesses to memory, in "ideal" conditions, you are gobbling 25 Mhz from the bus (200 Mbytes / 4 bytes = 50 million WORDs, at 2 DWORDs per memory access cycle) JUST to read scren pixels. And I say "ideal", because those 25MHz ASSUME "zero wait state" accesses. DDR2 memory is SLOWER than DDR, but as it operates on a DOUBLE speed bus, if you put some "magic" in the front side, you obtain frightening results. Basically, they put a "read cache" to memory.

If you intermix "easy and linear" accesses from the LCD controller with the "bitching and random" accesses of the processor doing million things per second, I GUARANTEE that with 25 Mhz YOU CAN'T read a second of video from RAM. Not on your life! He he he...
Swapping page in a DDR2 can take up to FIFTEEN clock cycles...

I remind you that those figures are only to read the memory bitmaps from the LCD controller... And I've not said A SINGLE WORD ABOUT DECODING MPEG4 HD!!!

And I give you another example: Microsoft recommends, for WMV 720p video playback, a 2.4 GHz processor... For playing 1080p (+audio 5.1) they recommend a Pentium IV at 3GHz, or a Core Duo (dual core), at least at 1.8GHz... And I ASSURE you that Microsoft's codecs are optimized to the MILLIMETER! He he he...
From the information commented on "http://blogs.msdn.com/xboxteam/archive/ ... e-day.aspx", the sixs hardware threads of a XBox 360 are TO THE TITS during playback of HD-DVD. And those are POWER processors.
And they are using the GPU to do a great deal of the decompression!!! Or, for example, look at the information for PowerDVD from Cyberlink, in the system requirements area, what they ask for to play HDDVD or Bluray: "http://www.cyberlink.com/multi/products ... 2_ENU.html)". And I insist: With graphics cards that COLLABORATE!!!!

What makes you think that it only uses single word 32bit fetches??
This assumption is unrealistic as the memory is 64bit.
I would rather assumed that is does at least 32 byte bursts like the CPU does.

Your brother is wrong :)

The software used to decode is a bespoke (commercial, non-Linux) MPEG4 decoder. Linux may have some overhead not present here. It is technically possible to run this amount of data through the AltiVec unit at ~1GHz with a 533MHz bus speed, with reasonable performance (i.e. it plays and doesn't skip). So, let this not be proof that you can play Blu-Ray discs under Ubuntu, but that it is technically possible under a contrived benchmark. The video purpose is to test the DIU driver at that resolution.

Let's make some assumptions; at 1066MHz and a 533MHz frontside bus, with DDR2 memory with a decent latency, using AltiVec and a pre-set-up display to decode MPEG4 data directly to the screen - there is no overlay, only RGB output, converted on the fly by the MPEG4 decoder, which is entirely done in AltiVec.

Yes, it's possible. Easily possible. Your brother is being distracted by the details; the chip is far, far simpler than he makes out.

Also remember the DIU is *not* like typical PC AGP/PCI Express graphics engines; it does not rely on a PCI arbiter to grant it time to access the graphics RAM, it is just a DAC which spins over some memory areas, and an interface to the same RAM the CPU uses.

It is CPU local memory. Your display performance is directly dependant on the speed of the CPU writing values to local memory. There is *no* bottleneck for PCI transfers or expensive local-to-AGP blits or tiling. It does not blit or colour convert. It is at the mercy of the CPU, and in this benchmark - well, imagine you did a non-displaying benchmark of decode performance of a 1080p video on a command line. The speed will be the same. There's no difference in displaying the data or just filling a memory buffer. Are you saying a 533MHz 64-bit bus can't handle the bandwidth required?

The "official" MPC8610 specification is that the display integration unit (DIU from here in) tops out at 1280x1024. There is some technical reason behind this; the DIU actually runs at a quarter of the system bus clock rate, so this is actually your DAC speed.

Let's assume the DIU reads one pixel per DIU clock.

At a 533MHz bus speed, the DIU can run at 133MHz - which is more than enough for 1920x1080 video at 60Hz (it's actually 128MHz).

You can actually run the system bus at 400MHz, and at this speed, you can't even promise a 1280x1024@60Hz display because it would require 107MHz. Obviously there are bus speeds inbetween which make it possible. Freescale are being safe with their values.

We're doubtlessly going to run the chip at 533MHz internally, so yes, you can do 1080p (HDTV resolution) but;

* unfortunately not 1920x1200 or 1920x1600 (common widescreen and 4:3 monitor resolutions)
* you COULD do 1600x1200@60Hz, 1600x1050@60Hz, myriad combinations inbetween to support most sub-24" monitors.

Quite how the unaccelerated DIU will fare at that resolution, is to be debated - AltiVec will help, here.

We're fairly confident we can decode and upscale 720p MPEG4 (not H.264) video to 1080p using AltiVec under Linux with all the overheads implied by running Linux. I am extremely confident the 1.3GHz MPC8610 model could decode 720p H.264 video on it's own (no filtering or scaling or clever tricks, just flat out decoding).

Decoding H.264 video and doing anything native resolution of 1080p might be a bit more of a chore, I will admit that. We have ideas to solve this, however.

As for your assertions about Microsoft; Windows DirectShow, the VMR9 renderer in RGB mode is an incredibly resource intensive thing with a lot of overhead. Windows is not architected for low-latency video and audio playback - they delayed Vista by 2 years to get this fixed, as an example. The Windows Media decoders are actually not as optimized as you might think - remember these specs were written when XP was young, and SSE3 did not exist.. :)

Apple's specs for playing back HD video on PPC Macs are not so high - and even then, they are fairly conservative. You definitely do not need a 2.8GHz Pentium 4 to play 1280x720p H.264 content because my 1.7GHz Pentium M, Radeon 9200 laptop manages it just as well - using the ffdshow codec and not a commercially optimized one.

As for the Xbox decoding issue, Microsoft have already admitted their video codecs are not that optimized there. The Xenon CPU is also in-order execution and has the same memory access problems as the G5 and Cell - if it is not extremely linear, it incurs severe penalties which gives them far less performance than you might think.

I very vividly remember a test performed by Jacob Pan (ex-Freescale engineer) at the SNDF Dallas show in 2004. This was just after the Mac G5 was launched. He had a demo; a Sandpoint G4 board and a Mac G5. There was a benchmark button you could click, and both systems would perform the same memory accessing, MPEG decoding etc. benchmarks and show the results.

At the same CPU clock speed, even with the higher FSB speed of the G5, even with 64-bit addressing and tons of memory, the G5 lost every single benchmark - none of which were particularly contrived, they were valid EEMBC stuff, which showed that being able to randomly access memory in arbitrary patterns is important, and the G4 core excels at it.

In the November Xbox 360 update the changelog was littered with optimisations for video codecs and mentions of VMX. How many years have Microsoft been supporting video decoding on PowerPC? Not even one! The Xbox 360 has some way to go, and then they will have cracked the video decoding issues.

_________________
Matt Sealey

Amazing read, gentlemen! Thank you all for these informations. I'll pass them all to my brother, who is very interested about this.