Good show can't wait to see what comes from this!

Hi Lcuk,

The best way to predict the future is to avoid it.
But what is the fun in that? you already have the kudos and you really have nothing to lose.

Virgin, eh? I used to be one of those. But then I one day I made a release and voila, a virgin I was no more. If I have one piece of advice, it is this: just do it. Of course in this day and age, you'll want to protect yourself. LGPL perhaps?

}:^)~
YARR!

*shhhh*

Capt'n, I have decided to release under the GPL and have de-crufted the code base.
I have created the project (https://garage.maemo.org/projects/liqbase/) and am trying to get everything configured at this end for SVN updating.
Between my lack of knowledge about SVN and being confined within the 810 (I do all compiling direct on the device) its proving a little tricky.

It should all be up and running soon enough though and then I can get back to actually developing stuff.

Good on you, bud!

Compiling directly on the tablet? That's mighty ambitious of you! Now I have *another* potential use for my tablet. Nothing like being able to code on the subway. The thought is mind warping.

I also have a new open source project planned, so keep us all posted on your foray into the world of public development, as I'm sure it'll be inspiring to more than just a few. I, personally, will be following your project with much interest.

A question. Disclaimer: I have extremely little assembly experience and none for ARM architecture, so forgive the imminent ignorance.

I assume that you're using the DSP in the OMAP to spit out pre-saved YUV graphics to the main display which allows for very fast full-screen updates, as it appealing the the DSPs specialization.

Aren't there DSP routines to convert RGB input to YUV readily? If so, couldn't they be used to convert RGB to the equivalent YUV colourspace and potentially speed up full-screen viewing for 'regular' RGB apps? Is this what libqbase already does?

I warned you that ignorance was coming! Anyway, if this is so, it would be GREAT if you could implement a wrapper, using libqbase, for a generic graphic library like SDL as it would INSTANTLY improve the performance of many full-screen applications.

Feel free to answer none of my questions!

}:^)~
YARR!

Zip Zap Cap

No. Talk to raster on #canola if you want to know the specifics of why this doesn't work.

Capt,

compiling on the tablet isn't that bad for this project. Each module is built in a couple of seconds and linkage is similar, its well within my annoyance threshhold at the moment. (if anything, this method is faster than the old way of using vmware scratchbox).

Being able to fixup bugs and do non trivial work on the go is amazing - i created the graffiti wall module whilst sat in the developer room at linuxtag earlier this year

There are a number of limitations which would prevent its use with other larger projects (lack of autotools is a major one) but it works for me.

I do not use the DSP for anything at this moment in time (and infact when the DSP is running the whole device runs slower..).
All code is aimed towards the cpu itself.

The amount of processing power required to do RGB->yuv conversion on the fly would make converting SDL a none trivial operation and I doubt would yeald acceptable performance benefits at this time (Lardmans DSP investiagations may surprise us!).

In the future however I am hopeful we can make use of the rest of the specialist hardware within the OMAP2420 chip package, this includes a hardware RGB->YUV conversion and of course the powervr 3d hardware but this appears to be a non-starter at the moment.

Another possibility is to use the same YUV graphics mode under X11 itself and actually run maemo very quickly in greyscale (sidestepping conversion altogether) - a major compromise, but something "technically" possible which linux/x11/maybe SDL supports (8bit greyscale framebuffers exist).

Thank you for your interest in the project and I am also hopeful that we can build an extensive collection of exciting software toys and projects to show off our nokias.

Patch the kernel for a different op_mode. Although saying that, I wouldn't expect you to expect endusers to do that

@GeneralAntilles

After looking a the conversion function, I can understand why it's not feasible to expect speed (or efficiency) gains calculating an RGB to YUV conversion in run-time:

Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

Although the formulae are linear and simple, there are two problems (as far as I can see). First, pixel setting is a PRIMITIVE operation and any calculation you add (even a simple one) tends to have a large impact due to the huge amount of times the operation is called. The next is the dreaded floating point, the Achilles heel of the N8x0, and this formula is ripe with floating MULs. Of course, the increased calculation will translate to an increased battery drain, which is not really good for anybody (except the sadists -- bless their little hearts).



@lcuk
Awesome. This has given me a ton of information and a much clearer idea of what's going on.

I'm betting that the simplest and quickest way to do run-time RGB to YUV conversion would be to use a pre-calculated lookup lookup table of conversions rather than run time calculation. Even storing a 16bit RGB to 16bit(?) YUV tabel would only require ~260K of system memory:

(2ByteRBG + 2ByteYUV) * 65536colours == 262144Bytes ~= 262K

[edit]
There is an error in this calculation. The correct size of the lookup should be:
2ByteYUV * 65536colours == 131072Bytes ~= 128K
It is not necessary to store the RGB index as a part of the table
[/edit]

SIDE NOTE: In this instance the N810s 16bit colour capabilities comes in really handy as it keeps the lookup small. 24bit would be quite a bit larger or require an additional bit shift to map the RGB to the YUV. Not terrible, but not ideal either.

Now when SDL sets a pixel, it does it the easiest way possible, by implementing a frame-buffer (block of memory) that you write directy to at a pre-calculated offset (depending on the depth and resolution).

This is where the wonderful compile-time construct the C/C++ macro definition comes in. If all of the pixel setting routines in an SDL app could be found, then they could be easily wrapped with a macro that compares the dynamic RGB with its YUV equivalent on the table *and* writes it to the frame buffer at the desired offset without requiring a costly function call.

To accomplish this, there will have to be a port and inspection of the code, but it *should* be straight forward enough to be done in an afternoon by a gifted porter. I'm guessing that the majority of applications would have their pixel setting done in only in a select few places anyway.

Now, using libQBase as a wrapper to an N810 specific version of the YUV SDL library (RGB/YUV macro lookup), we get minimally ported SDL apps that are spit out not to the X frame buffer, but more directly to the OMAP hardware. I'm guessing that there will be large speed increases for relatively little work!

I know I'm not telling you anything you don't know, just engaging in a little group problem solving. I'm confident that we can bust this nut wide open, figure out a way to squeeze new speed out of existing apps, and use libQBase to enable a new breed of N810 app.


Coding and *compiling* on the go is clearly amazing. I get excited just thinking about it!

How long would you say that battery lasts whilst coding up a few text files? What about reading text files (like documentation)?


I'm hopeful and confident as well. Keep moving forward and I'll see you there.


Cheers

}:^)~
YARR!
Capt'n Corrupt

I would like to add:

Setting anything other than full pixels in the method above would introduce another level of complexity, not solved by the methods above.

}:^)~
YARR!

Dr. Corrupt