Hi,
The memory bandwidth to the N800 LCD framebuffer is 3 times slower that
the bandwidth in the N770? Is it really _that_ big?
Siarhei's calculations were correct, so, yes.
What is limiting the bandwidth: The OMAP interface, the LCD controller
itself or was it a design issue.
a)
On Thursday 03 May 2007 10:21, Frantisek Dufka wrote:
Siarhei Siamashka wrote:
If decoding time for
each frame will never exceed 28-29ms (which is a tough limitation, cpu
usage is not uniform), video playback without dropping any frames will be
possible even with tearsync enabled.
On Friday 04 May 2007 10:49, Daniel Stone wrote:
On Thu, May 03, 2007 at 11:10:32PM +0300, ext Siarhei Siamashka wrote:
Well, found what's the matter and added explanation at bugzilla:
https://maemo.org/bugzilla/show_bug.cgi?id=1281
The workaround can be easily added to MPlayer, so that
On Thu, May 03, 2007 at 11:10:32PM +0300, ext Siarhei Siamashka wrote:
On Thursday 03 May 2007 08:48, Siarhei Siamashka wrote:
The only thing which is unclear here is that Hailstorm does not need to
downscale video in this situation. The bug can be reproduced with 512x288
video which just
Siarhei Siamashka wrote:
If decoding time for
each frame will never exceed 28-29ms (which is a tough limitation, cpu
usage is not uniform), video playback without dropping any frames will be
possible even with tearsync enabled.
Would a double or multiple buffering help with this? Does
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Looks like I have to reply to myself.
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
Applied and build without problems for me.
Thanks a lot for building the package and putting it for download,
everything seems to be fine, but
Kalle Vahlman wrote:
I put the deb up at:
http://iki.fi/zuh/xserver-xomap_1.1.99.3-0.zuh2_armel.deb
until I get it to the repository. This version also has the composite
extension enabled, but AFAIK it does not depend on the libs or change
server behaviour if composite is not specifically
On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote:
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Results with unpatched xserver and some more explanations can be found in
[3].
Yes, now N800 is faster than Nokia 770 for video output performance at
last :)
On Tue, May 01, 2007 at 08:49:20PM +0300, ext Siarhei Siamashka wrote:
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
For testing, I fabricated some video with gstreamer:
which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some
reason 320x240 and 352x288 refused to
On Tue, May 01, 2007 at 11:51:50AM +0300, ext Siarhei Siamashka wrote:
On Monday 30 April 2007 17:49, Daniel Stone wrote:
Indeed. Unfortunately this is slightly misleading in that it only shows
the raw write speed. RFBI can't deal with the sorts of speeds that your
hyper-optimised version
On 5/2/07, Quim Gil [EMAIL PROTECTED] wrote:
On Tue, 2007-05-01 at 03:29 -0300, ext Gustavo Sverzut Barbieri wrote:
Daniel, Siarhei, Eero: I always find your mails to provide great deal
of tech information about N800.
What a coincidence, me too. ;)
However we do not have a central place
Hi,
On Wed, May 02, 2007 at 10:05:13AM -0300, ext Gustavo Sverzut Barbieri wrote:
On 5/2/07, Quim Gil [EMAIL PROTECTED] wrote:
On Tue, 2007-05-01 at 03:29 -0300, ext Gustavo Sverzut Barbieri wrote:
Daniel, Siarhei, Eero: I always find your mails to provide great deal
of tech information
Daniel Stone wrote:
If there's anything you want to know directly, just ask on the list. I
tend to deal with email when I'm not actively coding/building/etc, which
is how I justify it. A wiki would require me to sit down for a while
and really think about stuff, and I don't really have huge
On Wednesday 02 May 2007 12:54, Daniel Stone wrote:
The 'framebuffer' is just the ordinary system memory, converting color
format and copying data to framebuffer will be done with the same
performance as simulated in this test. RFBI performance is only critical
for asynchronous DMA data
Don't kill the messenger!
But yeah, always happy to answer direct questions.
Disadvantage is that it becomes lost in the list archive.
This is an old problem communication science solved centuries ago:
generally you have those generating information and those collecting it.
Asking the sources
On Wednesday 02 May 2007 12:39, Daniel Stone wrote:
On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote:
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Results with unpatched xserver and some more explanations can be found
in [3].
Yes, now N800 is faster than
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
OK, here is this untested a patch for xserver to add ARMv6 optimized
YUV420 color format conversion. Theoretically it should compile
(I did not try to build xserver myself though) and work. If
On 4/30/07, Siarhei Siamashka [EMAIL PROTECTED] wrote:
On Friday 27 April 2007 04:43, Daniel Stone wrote:
[...]
Daniel, Siarhei, Eero: I always find your mails to provide great deal
of tech information about N800. However we do not have a central place
with these information, it would be
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
On Monday 30 April 2007 17:49, Daniel Stone wrote:
It's completely safe to upgrade from a deb if it's not broken. If you
set up a standard Maemo build environment and run apt-get source
xorg-server and apt-get build-dep xorg-server, it should
On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote:
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
OK, thanks. It may take some time though. I'm still using old scratchbox
with mistral SDK here (did not have enough free time to upgrade yet).
Until I clean up my scratchbox mess, I can only
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote:
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
OK, thanks. It may take some time though. I'm still using old scratchbox
with mistral SDK here (did not have enough free time to upgrade yet).
2007/5/1, Kalle Vahlman [EMAIL PROTECTED]:
The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp
-mfloat-abi=softfp -O2', but as I had troubles with the
SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not
guaranteeing it at the moment ;)
Actually seems that I had
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
OK, here is this untested a patch for xserver to add ARMv6 optimized
YUV420 color format conversion. Theoretically it should compile
(I did not try to build xserver myself though) and work. If it refuses to
compile, fixing the patch should
Frantisek Dufka wrote:
[sbox-SDK_ARMEL: ~/x/xorg-server-1.1.99.3] patch -p1
../xomap_yuv420patch.diff
patching file hw/kdrive/omap/Makefile.am
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 34.
2 out of 2 hunks FAILED -- saving rejects to file
hw/kdrive/omap/Makefile.am.rej
patching file
On 4/30/07, Daniel Stone [EMAIL PROTECTED] wrote:
There are two important optimizations in this code:
1. Cache prefetch with PLD instruction (added in '_armv5' version) which
boosts performance to 70 megapixels per second. Inner loop is unrolled
to process 32 pixels per iteration (cache
On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote:
about using ldmia/stdmia instructions to cluster sequential
that was supposed to be ldmia/sdmia, sorry.
Dan
___
maemo-developers mailing list
maemo-developers@maemo.org
On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote:
On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote:
about using ldmia/stdmia instructions to cluster sequential
that was supposed to be ldmia/sdmia, sorry.
Gah, ldmia/stmia, final answer.
Dan
___
On Friday 27 April 2007 04:43, Daniel Stone wrote:
I'll make a really optimized version of YV12 - YUV420 convertor on this
weekend (removing branch is good, but I feel that it can be improved
more) and will try to use it on Nokia 770, any extra video performance
improvement will be useful
Hi,
On Mon, Apr 30, 2007 at 02:27:49PM +0300, ext Siarhei Siamashka wrote:
On Friday 27 April 2007 04:43, Daniel Stone wrote:
I don't think Tornado supports YUV420, but I can check in the specs
tomorrow. My better C version basically does two macroblocks at a time,
ensuring all 32-bit
On Friday 20 April 2007 10:39, you wrote:
The primary conversion we do isn't planar - packed (this is a fallback
for when the video is obscured), but from planar to another custom
planar format. It would be good to get ARM assembly for the fallback
path, but most of the problem when using
On Tue, Apr 24, 2007 at 09:46:52AM +0300, ext Siarhei Siamashka wrote:
On Friday 20 April 2007 10:39, you wrote:
There's one optimisation that could be done for the YUV420 conversion
(the custom planar format that Hailstorm takes), which removes a branch,
ensures 32-bit writes always
On Monday 19 March 2007 22:34, you wrote:
snip
Again, if there are any particular questions I can answer, don't be
subtle: ask me straight up. If I can answer them (some things I can't
necessarily say, some things I don't necessarily know), I will.
Thanks, here we go and sorry for a long
Hi,
On Fri, Apr 20, 2007 at 09:41:45AM +0300, ext Siarhei Siamashka wrote:
1. Lockups which look like cycling two sequential frames, very similar or the
same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991
Also keypresses are not very responsive. A fix (or workaround) required
Daniel Stone wrote:
Which Epson docs?
fanoush.wz.cz/maemo/S1D13745A01SpecRev1.0.gm.zip
Got it from Epson Electronics like the one mentioned here
http://maemo.org/pipermail/maemo-developers/2006-December/006638.html
___
maemo-developers mailing
Siarhei Siamashka 写道:
I have seen your code in xserver which does the same job for downscaling, but
in nonoptimized C and with much higher impact on quality. Using JIT scaler
there can improve both image quality and performance a lot. The only my
concern is about instruction cache coherency. As
On Tuesday 20 March 2007 15:03, Klaus Rotter wrote:
On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote:
The memory bandwidth to the N800 LCD framebuffer is 3 times slower that
the bandwidth in the N770? Is it really _that_ big?
Siarhei's calculations were correct, so, yes.
Daniel Stone wrote:
On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote:
Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might
be caused by inefficient framebuffer driver implementation in its initial
revision. But if it is a hardware issue, getting normal
On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote:
Daniel Stone wrote:
On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote:
Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might
be caused by inefficient framebuffer driver implementation in
Daniel Stone wrote:
On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote:
The memory bandwidth to the N800 LCD framebuffer is 3 times slower that
the bandwidth in the N770? Is it really _that_ big?
Siarhei's calculations were correct, so, yes.
Bad... the N770 interface wasn't
On Tue, Mar 20, 2007 at 02:03:16PM +0100, ext Klaus Rotter wrote:
Daniel Stone wrote:
On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote:
The memory bandwidth to the N800 LCD framebuffer is 3 times slower that
the bandwidth in the N770? Is it really _that_ big?
Siarhei's
On Sun, Mar 18, 2007 at 07:57:36PM +0200, Siarhei Siamashka wrote:
I did some tests with the framebuffer when trying to find a way to reduce
tearing effect in MPlayer. Here are the results.
snip
This is a very interesting post. Thanks!
Marius Gedminas
--
... Another nationwide organization's
Siarhei Siamashka schrieb:
Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might
be caused by inefficient framebuffer driver implementation in its initial
revision. But if it is a hardware issue, getting normal video playback at
native framerate may be troublesome.
It
Hi,
On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote:
If we look at the framebuffer API. There are two ioctl important for screen
updates and tearing synchronization if I understand them correctly now:
[...]
You do indeed understand them correctly.
Looks like graphics
43 matches
Mail list logo
