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
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, s
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 enabl
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
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 needs upscaling to 800x450. Also even standard
> Nokia_N800.avi video with
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 mplay
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 w
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 f
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 sour
On Wednesday 02 May 2007 12:47, Daniel Stone wrote:
> > > X11 error: BadValue (integer parameter out of range for operation)
> > > MPlayer interrupted by signal 6 in module: flip_page while gstreamer
> > > did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died
> > > in the same way
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
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 bl
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 infor
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 plac
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 v
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 refu
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
> > las
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 use
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, bu
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 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
https://maemo.org/mailman
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 (cach
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
> with these information, it would be great if
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 hw/kdrive
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
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 a
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 y
Siarhei Siamashka 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 be not too difficult.
It doe
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
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 shoul
On Monday 30 April 2007 17:49, Daniel Stone wrote:
> > ARMv6 optimized YV12->YUV420 convertor is about 2.5x faster
> > than current code used in N800 xserver. So it should provide a nice
> > improvement for video :)
>
> Indeed. Unfortunately this is slightly misleading in that it only shows
> the
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 gre
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-b
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 b
On Fri, Apr 27, 2007 at 03:14:43AM +0300, ext Siarhei Siamashka wrote:
> On Tuesday 24 April 2007 12:36, Daniel Stone wrote:
> > Right, the branch is a problem, and as I said, the branch can be avoided
> > and the writes optimised to be three 32-bit writes for two macroblocks,
> > instead of two 32
On Tuesday 24 April 2007 12:36, Daniel Stone wrote:
> > My main performance concern is exactly about this
> > 'omapCopyPlanarDataYUV420' function. My experience from Nokia 770 video
> > output code optimization shows that optimization effect can be really
> > huge (it was 1.5x improvement on Nokia
On Mon, 2007-04-23 at 21:09:26 +0300, ext Siarhei Siamashka wrote:
> On Monday 23 April 2007 16:49, Guillem Jover wrote:
> > > You are right. gcc has function
> > > void __clear_cache (char *BEG, char *END)
> > > which should be more portable.
> >
> > It should, but it still has the problem of emit
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 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 usin
On Monday 23 April 2007 16:49, Guillem Jover wrote:
> > You are right. gcc has function
> > void __clear_cache (char *BEG, char *END)
> > which should be more portable.
>
> It should, but it still has the problem of emitting an OABI syscall
> due to our old gcc.
>
> You could use syscall(2) and __
On Mon, 2007-04-23 at 16:11:17 +0800, ext 黄涛 wrote:
> 2007/4/23, Siarhei Siamashka <[EMAIL PROTECTED]>:
> > Thanks, it works. But I'm worried about [1]. Looks like EABI has a new
> > syscall interface and this code from qemu uses old ABI. And from reading
> > description at the wiki page, compatibi
2007/4/23, Siarhei Siamashka <[EMAIL PROTECTED]>:
Thanks, it works. But I'm worried about [1]. Looks like EABI has a new
syscall
interface and this code from qemu uses old ABI. And from reading
description
at the wiki page, compatibility with old ABI can be disabled (and it makes
sense disabling
On Friday 20 April 2007 19:04, you wrote:
> > 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 abou
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 A
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 lis
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
>
On Monday 19 March 2007 22:34, you wrote:
> 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 dela
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 correc
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?
> >
> >Si
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 t
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 implementat
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 v
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 grap
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 w
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.
This is a very interesting post. Thanks!
Marius Gedminas
--
... Another nationwide organization's co
Hello All,
I did some tests with the framebuffer when trying to find a way to reduce
tearing effect in MPlayer. Here are the results.
I did a mistake when I assumed that screen updates are synchronous for video
planes. They are actually asynchronous just like with Nokia 770, but just a
lot slower
56 matches
Mail list logo
