Tomas Frydrych wrote:
There seems to be no source for the functions in the tarball.
Siarhei Siamashka wrote:
Hello All,
Here are the optimized memory copying functions for Nokia 770
(memset is more than twice faster, memcpy improves about 10-40%
depending on relative data blocks
Tomas Frydrych wrote:
Like Dirk already replied, the implementation is in macros in the .h
file.
I see. That makes the comparison with memcpy somewhat unfair, since you
are not actually providing replacement functions, so this would only
make difference for -O3 type optimatisation (where you
Eero Tamminen wrote:
That makes the comparison with memcpy somewhat unfair, since you
are not actually providing replacement functions, so this would
only make difference for -O3 type optimatisation (where you trade
speed for size); it would be interesting to see what the
performance
Siarhei Siamashka wrote:
...
It is strange that such 16-byte alignment trick was neither used in
uclibc nor in glibc until now. One more option is that this improvement
is only Nokia 770 specific and nobody else ever encountered it or had to
use. Well, do we really care anyway? ;)
Now I just
Simon Pickering wrote:
I don't know what version flash image that c760 was running, but my c750
produces better results. I compiled your test program in two versions - arm4
and arm5 using the default toolchains built by bitbake + OpenEmbedded for
the Zaurus sl-5500 and c7x0 machines
Weinehall David (Nokia-M/Tampere) wrote:
On ons, 2006-04-05 at 01:15 -0700, ext Aaron Levinson wrote:
On Wed, 5 Apr 2006, Weinehall David (Nokia-M/Tampere) wrote:
[snip]
Also, whether or not this application belongs on the Application Catalog
page, it's still appropriate to consult with the
Hello all,
We have a discussion about Nokia 770 specs in some Russian speaking
forum. We figured out that there is different information about
Nokia 770 cpu clock frequency floating around.
Some sources report 220MHz:
http://maemo.org/maemowiki/Nokia_770_Hardware_Specification
The others report
Disconnect wrote:
Will changelogs be provided later? (Not to threadjack this into the other
conversation, but this is a great example of where nokia can better their
interaction with the community in a fairly easy way. Even if some parts have
to be left out or summarized as Browser stability,
Daniel Monteiro wrote:
SDL would have a faster hardware access. On the other
hand , Maemo wold be better integrated with the
system, would not need the GameLauncher, etc.
I'm sorry to interfere, but is GameLauncher really needed?
SDL applications seem to run fine enough or I'm missing
On Friday 30 June 2006 09:24, Raju, Vanitha G wrote:
Is there a utility to read the processor speed? Or if you have the
register details which can be accessed to determine the speed - that
would be of help.
Maybe this can be of any use:
Hello All,
When trying to compile mplayer, I have noticed that there is libxv
packaged in maemo sdk and also it can also be installed using apt-get on
the real device. It is useless at least for mplayer though:
It seems there is no Xvideo support for your video card available.
Run 'xvinfo'
On Friday 14 July 2006 02:41, Steven Hill wrote:
Can anyone tell me either:
1. Where I can find an ARMEL version of libsqlite3-dev to use when
developing for the Nokia 770 IT2006 version, OR
2. Where I can find a port of the libsqlite0 package to the ARMEL IT2006
version.
Failing that, how
On Tuesday 25 July 2006 09:01, you wrote:
http://www.internettablettalk.com/forums/showthread.php?t=2405
Actually mplayer works surprisingly fast and has performance not much
inferior to default video player on Nokia 770 that is using DSP. And
that all is even without hardware
Hello All,
I'm trying to get current playing position from dspmp3sink, but
gst_element_query position() function fails. The same code works
fine for dsppcmsink.
Did anybody encounter such problem? What solution can be used?
___
maemo-developers
On Monday 21 August 2006 10:45, Detlef Schmicker wrote:
I had a look at the vncviewer and saw, that it is working in the sandbox
in connection with vino (gnome vnc server). On the device the CoRRE
encoding does not work.
Probably it is a byte order problem. The code has a lot of byte order
On Monday 21 August 2006 18:34, Charles 'Buck' Krasic wrote:
Just in case you have not done it already, enabling swap in your device
can help a lot to prevent out-of-memory errors.Maybe this will help
with mplayer/gstreamer stability.
I personally suspect a design flaw in the current
Hello All,
I'm sorry for a long chunk of quoted text at the end of this message
(it describes the sympthoms of the problem), but looks like I got an
almost reliable proof that there is something wrong with the hardware
of my device :(
I tried to find some software that could be used for
On Sunday 10 September 2006 11:36, Olivier ROLAND wrote:
Your test work fine on my device.
I see that you run it from /media/mmc1so I guess you format your memory
card with ext2.
Mine still vfat so I can't. If you got same error when running from
internal memory then your device is broken.
On Monday 11 September 2006 23:51, [EMAIL PROTECTED] wrote:
When executing: cat /proc/cpuinfo I see the following:
Processor : ARM926EJ-Sid(wb) rev 3 (v5l)
BogoMIPS: 125.76
Features: swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU
On Monday 11 September 2006 00:34, Olivier ROLAND wrote:
After playing with the device for some time, I got the same problem with
lzma program this evening. And memtester also confirms that the memory is
really defective :(
# ./memtester 20
memtester version 4.0.5 (32-bit)
Copyright
On Tuesday 19 September 2006 00:03, you wrote:
[...]
An interesting observation is that you need to gradually increase the size
of tested memory block. You need to start with testing 20MB first, then you
can try 25MB and so on up to 43MB. If you try to allocate and test a large
block of
On 9/19/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote:
Yes, it would need to be reproducible in several different devices. The
guy here that tried to reproduce it currently thinks that Siarhei's unit
is broken.
Yes, I also think that the probability of my device being broken is
quite high. A
On Wednesday 20 September 2006 01:12, Olivier ROLAND wrote:
If your device is broken then mine is also.
I don't think at all that we speak about (small) fraction because
majority of users won't even notice the problem.
My device seem stable until I stressed it. And stressed it is not a
Hello All,
What do you think about current wiki based application catalog? In my
opinion, it is quite a large page already, slow to open and hard to
navigate. As I see it now, maemo-apps.org looks like it may become an
interesting resource for maemo community in the future. But it lacks
content,
On Wednesday 18 October 2006 16:26, Mike Frantzen wrote:
On Tue, Oct 17, 2006 at 11:50:03AM +0200, Malix wrote:
Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770
reboot. This happen some times when I'm using the browser and every
time I try to use Gizmo. For now I
On Wednesday 18 October 2006 15:58, Amit Kucheria wrote:
On Wed, 2006-10-18 at 13:00 +0300, ext Marius Gedminas wrote:
On Tue, Oct 17, 2006 at 11:50:03AM +0200, Malix wrote:
Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770
reboot. This happen some times when I'm using
On Monday 13 November 2006 22:08, Andrew Barr wrote:
What are my options for Windows Media Audio streams on the 770? Most
Internet radio streams (I mean simulcasts of real broadcasts in this sense)
are offered in (at least) this format, which is supported by free software
(ffmpeg) up to
On Thursday 23 November 2006 22:19, Charles 'Buck' Krasic wrote:
No, my dsp work was actually video related.I did reuse Siarhei
Siamashka's mplayer code to decode/output mp3 directly, but that
obviously doesn't help with speex.
Just a disclaimer before anybody starts bashing my ugly hack
On Saturday 25 November 2006 19:05, George Farris wrote:
On Sat, 2006-25-11 at 18:34 +0200, Stefan Kost wrote:
Hi George,
To make it a bit more clear: If there are plans, we would not be allowed
to talk about it :(. So you'll have to wait. But be assured it if is
technically doable its
On Thursday 23 November 2006 21:02, you wrote:
On Monday 13 November 2006 22:08, Andrew Barr wrote:
What are my options for Windows Media Audio streams on the 770? Most
Internet radio streams (I mean simulcasts of real broadcasts in this
sense) are offered in (at least) this format, which
Hello All,
Here is an old link with some benchmarks and initial information:
http://maemo.org/pipermail/maemo-developers/2006-March/003269.html
Now for more completeness, memcpy equivalent is also available and
the functions exist in two flavours (either gcc inline macros, or just
assembly
Hello All,
I have just uploaded a new build of mplayer (mplayer_1.0rc1-maemo.3) to
garage, which implements some experimental and not yet clean video output
method using hardware YUV colorspace and direct access to framebuffer. It's
not quite usable as framebuffer access is not allowed when
On Monday 11 December 2006 11:26, Frantisek Dufka wrote:
Yes, the result would look like video overlay works in windows or linux
on PC - overlay draws over different windows when it shouldn't :-) We
can live with that.
I thought it is actually not a problem but quite a good thing :-) Surely
On Tuesday 12 December 2006 01:57, you wrote:
My original goal of posting the previous message was an attempt to find a
volunteer who would like to try developing such a frontend.
I don't have that much time to devote to mplayer development myself. Up
until this moment I even could not
On Monday 08 January 2007 09:02, Komal Shah wrote:
Ok. Let's fun begin.
It looks like OMAP2420 only. As per the development track on
linux.omap.com kernel mailing list the product may _NOT_ be using the
IVA1.0 processor. Basically OMAP2420 from the multimedia point of view
is a MPEG4
On Saturday 13 January 2007 21:00, Kalle Vahlman wrote:
We have all sorts of funny hardware at the office, so I thought I'd
make a quick run of cairo-perf with the Cairo 1.3.10 snapshot and see
how they relate to each other.
There's some funny things I encountered in the results, and I hope
On Sunday 14 January 2007 20:11, Frantisek Dufka wrote:
Marius Gedminas wrote:
On Sun, Jan 14, 2007 at 07:53:06PM +0200, Marius Gedminas wrote:
On Sun, Jan 14, 2007 at 12:11:37AM +0200, Siarhei Siamashka wrote:
Also Nokia 770 runs not at 220MHz as stated on your page, but at
something
On Tuesday 16 January 2007 12:08, Zeeshan Ali wrote:
Now, the recently announced Nokia N800 is different from the 770 in
various ways that are interesting for Cairo performance. I've got my
eye on the ARMv6 SIMD instructions and the PowerVR MBX accelerator.
Yeah! me too. The combined
On Wednesday 10 January 2007 01:51, Charles 'Buck' Krasic wrote:
Siarhei Siamashka wrote:
Actually I have been thinking about trying to implement Xvideo
support on 770 for some time already. Now as N800 has Xvideo
support, it would be nice to have it on 770 as well for better
consistency
On Thursday 18 January 2007 13:46, Gustavo Sverzut Barbieri wrote:
By the way, free software is really poorly optimized for ARM right now.
For example, SDL is not optimized for ARM, xserver is probably not
optimized as well, a lot of performance critical parts of code in various
software
Hello,
It would be probably a good idea to discuss different possibilities for
improving multimedia support on 770/N800.
Now we have a fast JIT scaler that runs on ARM core, it solves all the
video resolution related performance problems. I'm going to work on
improving quality, performance
On Friday 09 March 2007 12:20, Daniel Stone wrote:
On Fri, Mar 09, 2007 at 09:45:03AM +0100, ext Hanno Zulla wrote:
Right now, the biggest bottleneck in video decoding is RFBI bandwidth
(i.e. the bus between OMAP and the LCD controller we use), being too
slow to push more than ~15fps
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
On Wednesday 21 March 2007 09:58, Sampath Goud wrote:
I want to know if there is frame buffer support in N800.
I have written a simple application (drawing a pixel) on frame buffer and
tried to execute it on N800 in root mode.
But it prompts the message permission denied.
Please let me know
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.
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
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 about
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 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 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
On Tuesday 24 April 2007 10:56, you wrote:
By the way, do you have any plans for upgrading toolchain? Either I'm
extremely unlucky, or current toolchain is really very buggy.
You can see the known issues from the GCC bugzilla.
There are a few bugs in C++ support which have been fixed
in
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
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
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
On Monday 30 April 2007 12:26, Frantisek Dufka wrote:
Daniel Stone wrote:
Specifying that pixels must be exactly _doubled_ is a
hack around both the performance issues and a lack of resolution
independence. Apparently an important one, if you happen to like SDL
games, but a hack
On Wednesday 02 May 2007 20:40, Daniel Stone wrote:
For the use case which is being described here - namely always full
screen applications which need exclusive access to the display at a
lower resolution Why not do something like switch to another VT and do
it directly on the framebuffer
On Wednesday 02 May 2007 18:48, Eero Tamminen wrote:
On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as
that way one can browse the source code interactively with
the profiling information. Getting to know how the source
really works is sometimes more useful than knowing the exact
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote:
If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps
would use only 12 percent of that bandwidth
I'm sorry, I was the source of this misleading information, I forgot that
you are a Nokia 770 user and mentioned some
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
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
On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote:
[...]
Same problem as using framebuffer directly. How user switches
to another application? How to invoke power menu properly etc.
What problem with using framebuffer directly? Everything should be
fine, you can get notifications from
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 Monday 30 April 2007 14:27, Siarhei Siamashka wrote:
I also tried to use YUV420 on Nokia 770, but it did not work well.
According to Epson, this format should be supported by hardware. Also there
is a constant OMAPFB_COLOR_YUV420 defined in omapfb.h in Nokia 770 kernel
sources
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
On Thursday 03 May 2007 12:58, Eero Tamminen wrote:
ext Siarhei Siamashka wrote:
What problem with using framebuffer directly? Everything should be
fine, you can get notifications from xserver when your window becomes
obscured, so you can stop drawing. I suggest you to try MPlayer
On Friday 25 May 2007 11:42, Juuso Räsänen wrote:
I have been trying to compile MPlayer myself under Maemo 3.1.
I've used patches from:
https://garage.maemo.org/frs/?group_id=54
However, commands...
[sbox-SDK_ARMEL: ~/MPlayer-1.0rc1-maemo.16] ./configure
[sbox-SDK_ARMEL:
On Wednesday 18 July 2007 13:01, Simon Pickering wrote:
Does anyone know whether there are there any good docs/books on ARM asm
programming, telling people these sort of things? This is an interesting
(and hopefully useful) learning experience, but can be really frustrating
when I know what I
On 30 August 2007, Jesse Guardiani wrote:
Koen Kooi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Guardiani schreef:
And the related question is: given an existing program that sends
stuff out to ALSA and doesn't use gstreamer, how difficult is it
generally
On 14 September 2007, Charles 'Buck' Krasic wrote:
I did some experimentation a while back with DSP - ARM communication
via mmap'ed memory, in my case I was working on using the DSP for rgb
to yuv conversion. Another big gotcha to look out for is 64k
boundaries. The DSP (at least in the 770)
On 30 December 2007, Frantisek Dufka wrote:
Krischan Keitsch wrote:
I was wondering if the device really needs to run at 300MHz (220MHz dsp)
for mp3 playback? Is the max dsp power needed for such a task? Or would
220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower
dsp
On 31 December 2007, Frantisek Dufka wrote:
Igor Stoppa wrote:
Having the audio path open, but no dsp tack loaded (arm audio) sets the
clock to 400MHz.
Interesting, so, umm, there is way to play audio from ARM side directly?
What I tried is to play BBC radio in home screen applet which
On Feb 17, 2008 9:56 PM, Tobias Oberstein [EMAIL PROTECTED] wrote:
[...]
I've read a lot of bits on the web 'bout mplayer, vsync, omapfb etc.
and tried to assemble a minimal example of using direct framebuffer
access for gfx output.
Q: I can't get the tearing away (only fixed at certain
On Feb 18, 2008 9:39 AM, Tapani Pälli [EMAIL PROTECTED] wrote:
When using the supplied SDL library for doing timer-based frame
rendering, there seems to be
- heavy tearing
Tearing unfortunately happens because there is no vsync available for
framebuffer driver to use.
Could you please
On Feb 18, 2008 1:28 PM, Tapani Pälli [EMAIL PROTECTED] wrote:
Could you please verify and confirm this information? Framebuffer
driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC
flag as Frantisek mentioned), and it was used at least for video.
Well, I have noticed
On Feb 14, 2008 8:43 AM, Kalle Valo [EMAIL PROTECTED] wrote:
[...]
other users reported it too as Luca Olivetti pointed out. and it
seems like the problem and fix is described here:
http://internettablettalk.com/forums/showpost.php?p=134914postcount=15
at least for the 770 the fix
On 22 February 2008, Frantisek Dufka wrote:
Kalle Valo wrote:
Also CPU usage is very high because of busyloop when waiting till
DMA transfer is done. Tasklet, which executes the code can't be
easily preempted, as far as I understand kernel documentation. Maybe
it is possible to split
On 3 March 2008, Gustavo Sverzut Barbieri wrote:
On Sun, Mar 2, 2008 at 2:17 PM, Vinod Hegde [EMAIL PROTECTED] wrote:
Hi Everyone,
How do I access the hardware performance counters available in OMAP2420.
what are the header files that contain the implementation.
I tried lots to figure
,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
On Thu, Jul 10, 2008 at 2:06 PM, Simon Pickering
[EMAIL PROTECTED] wrote:
The change which has allowed it to encode an entire song rather than just
a
few seconds was to move the input and output buffers from SDRAM (OMAP main
memory) to SRAM (DSP fast single access memory). There are probably
On Thu, Jul 10, 2008 at 6:57 PM, Simon Pickering
[EMAIL PROTECTED] wrote:
No, I understood, I was just mentioning that there appear to be two
heaps to chose from - presumably one is used by the DSP tasks (malloc is
probably #defined as one of the CSL MEM* fns in the DSP Gateway task
/docs/prod/folders/print/tlv320aic23b.html
3. http://thread.gmane.org/gmane.linux.ports.arm.omap/11700/focus=11709
4.
https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html
5. http://www.gossamer-threads.com/lists/maemo/developers/30611
--
Best regards,
Siarhei Siamashka
On Thursday 25 September 2008, Felipe Contreras wrote:
On Thu, Sep 25, 2008 at 10:07 PM, Siarhei Siamashka
[...]
Now regarding why we may want it. Once if we get a good, low latency,
fully functional and reliable ALSA sound driver running on ARM, it gives
maemo community a nice possibility
can't say the same for N8x0 at the moment, because free DSP
toolchain from TI does not support compilation of DSP kernel for OMAP2
according to dspgateway documentation.
--
Best regards,
Siarhei Siamashka
--- dspgw-3.3-dsp.orig/tokliBIOS/tokliBIOScfg.tcf 2005-06-09 07:28:21.0 +0300
+++ dspgw
On Friday 26 September 2008, Robert Schuster wrote:
Hi,
Siarhei Siamashka schrieb:
Recently I have been trying to make it running and seems like we have a
very good chance to have it working nicely. It is also interesting, that
the linux-omap guys seem to be developing a new driver [3
frameworks and layers are used, chances
of having something implemented inefficiently in between get a bit higher.
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo
On Tue, Jan 13, 2009 at 10:56 AM, Frantisek Dufka duf...@seznam.cz wrote:
BTW, there is kernel ioctl to set automatic refresh and the refresh rate
can be tweaked in kernel source but the results are suboptimal. Maybe at
least for Nokia 770 it would be possible to use tearsync flag for such
On Tue, Jan 13, 2009 at 12:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote:
Hi,
On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote:
Hi, Igor Stoppa:
Thank you for your reply!
So can I
the following page:
http://maemo.org/development/tools/doc/diablo/oprofile/
If you think that for your specific case gprof is better and doubt that
oprofile can handle it well, please describe what exactly you want to do.
I'll try to advice something.
--
Best regards,
Siarhei Siamashka
On Tuesday 13 January 2009, Frantisek Dufka wrote:
Siarhei Siamashka wrote:
XV should make a perfect backend for SDL, because it maps fine on SDL
API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend
for anything that uses double-buffered or triple-buffered
fullscreen
confirm that
XV rotates correctly as well ;)*
Gary Birkett (lcuk in #maemo)
By the way, have you reported this XV rotation problem to the authors of the
unofficial rotation patch? What did they reply?
--
Best regards,
Siarhei Siamashka
___
maemo
ownership to you. Maybe they don't have time
or have other reasons not to work on the project actively and will be
glad to know that somebody wants to take it over.
--
Best regards
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers
benchmarking -O0 code, because in
this case all the local variables are kept in memory and are read/written
before/after each operation. It's substantially different from normal code.
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
faster on more complex code
examples where it can actually benefit from pipelining. On x86, SSE2 is used
quite nicely for floating point math.
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
https
On Wednesday 10 March 2010, Laurent Desnogues wrote:
On Wed, Mar 10, 2010 at 8:54 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
[...]
I wonder why the compiler does not use real NEON instructions with
-ffast-math option, it should be quite useful even for scalar code
already assumes no support for NaNs. Even if
there are other nice IEEE754 things preventing NEON from being used
with -ffast-math, an appropriate new option relaxing this requirement
makes sense to be invented.
--
Best regards,
Siarhei Siamashka
___
maemo
On Wednesday 10 March 2010, Laurent GUERBY wrote:
On Wed, 2010-03-10 at 21:54 +0200, Siarhei Siamashka wrote:
I wonder why the compiler does not use real NEON instructions with
-ffast-math option, it should be quite useful even for scalar code.
something like:
vld1.32 {d0[0]}, [r0
96 matches
Mail list logo
