Hello,
i am just wondering which omap-model will be used by the new
beagleboard xm and if it will be able to display 1080p over DVI-D.
And if there are any plans to include the TI-WiLink 7 chip for GPS,
Bluetooth, Wifi and FM in the near future.
Regards,
Thomas
A yet to be announced processor will be used. It will not support 1080. It does not include TI-Wilink on the board. It does not support Bluetooth on the board. It does not support GPS on the board. It does not support FM on the board.
Gerald
messier <messier31@gmx.net> writes:
Hello,
i am just wondering which omap-model will be used by the new
beagleboard xm and if it will be able to display 1080p over DVI-D.
The Beagle XM will use the OMAP3, just like the current Beagle. It
supports 1080p30 output, but not 1080p60.
Gerald Coley <gerald@beagleboard.org> writes:
A yet to be announced processor will be used. It will not support 1080.
Not even 1080p30 like the current OMAP3?
Måns Rullgård <mans@mansr.com> writes:
messier <messier31@gmx.net> writes:
Hello,
i am just wondering which omap-model will be used by the new
beagleboard xm and if it will be able to display 1080p over DVI-D.The Beagle XM will use the OMAP3, just like the current Beagle.
Seems I got my facts mixed up, as Gerald just replied that it will use
a different chip.
The devcie used is a 1GHZ ARM Cortex A8 with the same DSP as the OMAP3530 (running faster) and the same SGX accelerator (running faster) and the same Neon processor. It also has 512MB DDR (running faster). If these added capabilities allow you to do 1080P at 30 then the answer would be yes. As I have yet to see that SW run on the device, I am not in a position to say whether such SW does indeed exist.
Gerald
2010/4/10 Måns Rullgård <mans@mansr.com>
Gerald Coley <gerald@beagleboard.org> writes:
Måns Rullgård <mans@mansr.com> writes:
> messier <messier31@gmx.net> writes:
>
>> Hello,
>>
>> i am just wondering which omap-model will be used by the new
>> beagleboard xm and if it will be able to display 1080p over DVI-D.
>
> The Beagle XM will use the OMAP3, just like the current Beagle.Seems I got my facts mixed up, as Gerald just replied that it will use
a different chip.The devcie used is a 1GHZ ARM Cortex A8 with the same DSP as the OMAP3530
(running faster) and the same SGX accelerator (running faster) and the same
Neon processor. It also has 512MB DDR (running faster). If these added
capabilities allow you to do 1080P at 30 then the answer would be yes. As I
have yet to see that SW run on the device, I am not in a position to say
whether such SW does indeed exist.
The OMAP3530 is can perfectly well _display_ 1080p30. It cannot
decode video of that size, but it could still be useful for running a
high-resolution desktop. Whether or not the new CPU can decode
1080p video remains to be seen, but I'm doubtful.
Thanks, for the quick responce. If the OMAP3530 is capable to display
1080p, is it not a question of the used codec if it also can decode a
video at that resolution?
And the thing with WiLink 7 was just a hint, what would be nice for
the future 
Regards,
Thomas
Elsewhere on this list it has been suggested by people in the know
that the yet to be announced CPU is likely to be the yet to be
announced DM3730 and will be almost identical to the OMAP3630 (except
clocked at 1GHz - which might make it closer to the OMAP3640).
messier <messier31@gmx.net> writes:
Thanks, for the quick responce. If the OMAP3530 is capable to display
1080p, is it not a question of the used codec if it also can decode a
video at that resolution?
The OMAP3530 can't decode 1080p video with any codec. Memory
bandwidth is a limiting factor as well as CPU speed.
decode fps is a factor ofcourse I guess what Mans is trying to explain here is the follows: even if the display is at 1080p resolution, there needs to be processing to be done to convert a 1080p wmv/avi file to the final RGB output (which is actually put in the display buffer). if you have a 30fps video and you dont render all 30 fps at the right time, you start seeing missing frames/lagging frame etc.. not a very pretty sight ;).. now if all you want to do is 1 frame per second, mebbe you could do it, except it makes no practical sense in a real world scenario.. in fact you could in theory do a "1080p" decode with a z80 or a 8086 and do 1 frame in x number of mins or so even.. but does it really matter other than being a curio?
Regards,
NM
YUV422 would be better, needs a lot less bw than rgb and can be handled by the DSS>
regards,
Koen
Nishanth Menon <menon.nishanth@gmail.com> writes:
messier<messier31@gmx.net> writes:
Thanks, for the quick responce. If the OMAP3530 is capable to display
1080p, is it not a question of the used codec if it also can decode a
video at that resolution?The OMAP3530 can't decode 1080p video with any codec. Memory
bandwidth is a limiting factor as well as CPU speed.decode fps is a factor ofcourse
explain here is the follows: even if the display is at 1080p
resolution, there needs to be processing to be done to convert a 1080p
wmv/avi file to the final RGB output (which is actually put in the
display buffer).
The display hardware accepts YUV input directly, although only in
4:2:2 format, so the 4:2:0 format typically produced by decoders must
be converted.
Displaying a 1080p30 image in YUV 4:2:2 format (2 bytes per pixel)
requires 1920*1080*2*30 ~= 120MB/s to be read from framebuffer RAM.
Writing it requires the same bandwidth again. The 4:2:0 format (1.5
bytes per pixel) from the decoder must also be written (by the decoer)
and read (by the conversion code), which makes for another
1920*1080*1.5*30*2 ~= 180MB/s. In the decoder, most blocks are
predicted, so (at least) one more frame's worth of data must be read
to produce the new frame. Add the same amount again for the
residuals. All together, we end up with something like this:
+------------------------ width
> +----------------- height
> > +---------- bytes per pixel
> > > +---- frames per second
> > > >
1920 * 1080 * 2 * 30 read by DSS
+ 1920 * 1080 * 2 * 30 write by format conversion
+ 1920 * 1080 * 1.5 * 30 read by format conversion
+ 1920 * 1080 * 1.5 * 30 write by decoder
+ 1920 * 1080 * 1.5 * 30 reference read (in decoder)
+ 1920 * 1080 * 1.5 * 30 residual read (in decoder)
+ 1920 * 1080 * 1.5 * 30 residual write (in decoder)
Thank you all for the explanation. I forgot about the memory
bandwidth.
Too bad, the beagleboard would make an excellent HTPC, considering the
small size and the low power consumption.
So i am waiting for an OMAP4 version. Is there any chance that this is
going to happen this year?
Nishanth Menon <menon.nisha...@gmail.com> writes:
>> messier<messie...@gmx.net> writes:>>> Thanks, for the quick responce. If the OMAP3530 is capable to display
>>> 1080p, is it not a question of the used codec if it also can decode a
>>> video at that resolution?>> The OMAP3530 can't decode 1080p video with any codec. Memory
>> bandwidth is a limiting factor as well as CPU speed.> decode fps is a factor ofcourse
> explain here is the follows: even if the display is at 1080p
> resolution, there needs to be processing to be done to convert a 1080p
> wmv/avi file to the final RGB output (which is actually put in the
> display buffer).The display hardware accepts YUV input directly, although only in
4:2:2 format, so the 4:2:0 format typically produced by decoders must
be converted.Displaying a 1080p30 image in YUV 4:2:2 format (2 bytes per pixel)
requires 1920*1080*2*30 ~= 120MB/s to be read from framebuffer RAM.
Writing it requires the same bandwidth again. The 4:2:0 format (1.5
bytes per pixel) from the decoder must also be written (by the decoer)
and read (by the conversion code), which makes for another
1920*1080*1.5*30*2 ~= 180MB/s. In the decoder, most blocks are
predicted, so (at least) one more frame's worth of data must be read
to produce the new frame. Add the same amount again for the
residuals. All together, we end up with something like this:\+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- width > \+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- height > > \+\-\-\-\-\-\-\-\-\-\- bytes per pixel > > > \+\-\-\-\- frames per second > > > > 1920 \* 1080 \* 2 \* 30 read by DSS+ 1920 * 1080 * 2 * 30 write by format conversion
+ 1920 * 1080 * 1.5 * 30 read by format conversion
+ 1920 * 1080 * 1.5 * 30 write by decoder
+ 1920 * 1080 * 1.5 * 30 reference read (in decoder)
+ 1920 * 1080 * 1.5 * 30 residual read (in decoder)
+ 1920 * 1080 * 1.5 * 30 residual write (in decoder)
--------------------------
715392000 grand totalThat's 700 MB/s of bandwidth just for moving pixel data around. That
is well over half the theoretical maximum memory bandwidth with
2*166MHz DDR RAM as found on the current Beagle. In reality such
rates are impossible to achieve due to access latencies etc.
Furthermore, a complex codec like H.264 can easily require twice that
memory bandwidth internally with multiple references, deblocking
filters, etc.Considering that the CPU will spend a lot of time processing the data,
not only reading and writing pixels, it is easy to see that 1080p
video on the current Beagle is impossible no matter what.> if you have a 30fps video and you dont render all 30 fps at the
> right time, you start seeing missing frames/lagging frame etc.. not
> a very pretty sight ;).. now if all you want to do is 1 frame per
> second, mebbe you could do it, except it makes no practical sense in
> a real world scenario.. in fact you could in theory do a "1080p"
> decode with a z80 or a 8086 and do 1 frame in x number of mins or so
> even.. but does it really matter other than being a curio?Yes, any size video can be decoded on anything, given enough time. I
assumed we were talking about real-time playback.
IIRC, the maxmum pixel clock rate is 72MHz. Even if decoding speed can
reach
30fps by assistance of DSP module, the display rate can not.
IIRC, the maxmum pixel clock rate is 72MHz. Even if decoding speed can
reach
30fps by assistance of DSP module, the display rate can not.
This is just a limitation in the linux driver only, at least at one
time it was. The hardware can go beyond that, e.g. I have played with
1280x1024x60Hz - which uses a 108Mhz pixel clock (one of the few pixel
clocks rates that actually fall out exactly with the division of the
system clock available). I couldn't work out how to get the PLL to
work so that was as high as I could go and still create a valid
signal.
Kai <kaijun61@yahoo.com> writes:
IIRC, the maxmum pixel clock rate is 72MHz. Even if decoding speed
can reach 30fps by assistance of DSP module, the display rate can
not.
The maximum supported pixel clock is 86MHz. If you're lucky, you can
push it a bit higher. 1080p30 uses a pixel clock of 74.25 MHz, well
within the supported range.
The memory bandwidth figures I gave apply equally to decoding on ARM,
DSP or some combination of both.