Re: [Open2x-devel] SDL_GetTicks optimization

[U. N. O. <ri...@ho...>]

>I thought I better send you a public thank you for the SDL YUV patch.
>As you know this has now gone into the newer SDL 1.2.11/GP2X codebase.

you're welcome :)

>I did however have a few questions. In the code you mention that the only
>supported YUV format on the GP2X is 4:2:2 (YUY2). I assume you arrived at
>the conclusion looking at the docs for the Video Processor?

yes, the native YUV format for the gp2x seems to be YUY2.

>I was wondering if you had looked at this as part of the work you did (i.e.
>is this a dead end and I just don't realise it) or if it was something that
>you did not consider.
>I have not had a chance to have a play with it myself yet but on paper at
>least it has merit.

I have read over the MMSP2 PDF "documentation" but haven't tried doing 
anything with the registers.  It's sure hard without example code.

>Anyway, I am just musing here but personally I can see a strong attraction
>of additionally adding support for SDL_YV12_OVERLAY even if the support 
>just
>internally converts it to YUY2.

This would be better than the current software-only solution.  I personally 
don't need YV12 support right now, but if someone else wants to tackle this, 
I would be happy to provide the algorithm to convert YV12 to YUY2 and also 
provide some advice on how best to accomplish this.

>You mentioned on IRC that you had hit a snag with the GetTicks work?
>The hardware timer was resetting after 10 mins as I understand it.
>
>Whilst there are several workarounds to this I can't see that any of them
>would be that elegant, you mentioned creating a SDL_GP2X_GetTicks, this
>strikes me as the cleanest approach for now but I am still slightly shocked
>by your timer findings.
>
>Could you provide a little more info on what you tried/used etc. maybe a
>wider group could shed some light on the issue and bottom out a nice way to
>tackle it.

Sure... the gp2x's timer is located at 0x0A00 (ie C000 0A00h) and you can 
read about it in that MMSP2 PDF file on page 168.  The docs say that the 
timer ticks every 7.3728MHz so to convert the timer to milliseconds, you 
need to divide by 7372.8 (or 7373 to avoid floating point math at the cost 
of some accuracy).  It also says that the timer rolls over to 0 once it 
passes 0xFFFFFFFF, so by doing a little math, you can see that this amounts 
to a little under 10 minutes.

There are a few ways to take advantage of this timer:
a) SDL_GetTicks, with some global variables as state to hide the 
"wraparound" from the user.
Pros: compatible with current SDL_GetTicks definition.
Cons: not thread safe, program must call SDL_GetTicks at least once every 10 
minutes or a wraparound will be lost.  Also precision will be lost, assuming 
we divide by 7373 instead of 7372.8.

b) SDL_GP2X_GetTicks with the user supplying a structure to hold state 
instead of using global variables.
Pros: thread safe
Cons: not compatible with SDL_GetTicks.  Must be called at least every 10 
minutes to ensure wraparound is detected.  Also, same problem with precision 
if we divide by 7373.

c) SDL_GP2X_GetMiniTicks which does nothing but returns the contents of 
0xA00 (the 10 minute timer).
Pros: thread safe, user can decide whether to divide by 7373 or 7372.8, does 
not need to be called every 10 minutes.
Cons: user will need to compensate for wraparound themselves, not compatible 
with SDL_GetTicks


After giving this a lot of thought, I prefer 'c'.  I think an 
SDL_GP2X_GetMiniTicks provides the user with the most flexibility and will 
work in every case.  SDL_GetTicks will still be available and will still 
work, it will just be slow (which is the current problem with it).

_________________________________________________________________
Get a preview of Live Earth, the hottest event this summer - only on MSN 
http://liveearth.msn.com?source=msntaglineliveearthhm