[FFmpeg-devel] pre discussion around Blackfin dct_quantize_bfin routine
Marc Hoffman
mmh
Tue Jun 12 11:53:41 CEST 2007
On Jun 12, 2007, at 5:49 AM, Guillaume Poirier wrote:
> Hi,
> Reimar Doeffinger wrote:
>> Hello,
>> On Mon, Jun 11, 2007 at 10:58:00PM -0400, Marc Hoffman wrote:
>>> This is my rough draft it works well with the small precision errors
>>> due to 16bit arithmetic, actually its the same (as far as I can
>>> tell)
>>> as the MMX quantizer. I ran my reference fixpoint against the mmx
>>> and
>>> it seems to work on the cases I tried, its 1 bit off which seems
>>> about right considering the truncation of the coeffs from 22 to
>>> 16bits. Can someone look over my shoulder and give a peak. I know I
>>> have to clean up the codes a bit but I wanted to get someone else to
>>> review my work up until now. I have used inline asm, Michael this
>>> should be pretty straight forward for you to get your head around.
>>> This doubles the performance roughly.
>>
>> Hmm. Ok, most is cleanup suggestions so I might be telling you things
>> you already know, still...
>>
>>> #define clock() ({ int _t; asm volatile ("%0=cycles;" :
>>> "=d" (_t)); _t; })
>>
>> If you leave that in the final version you should probably use a less
>> collision-freindly name like bfin_clock or so.
>> Also that ({ }) construction is a nasty gcc-ism, you could avoid
>> it by
>> making it a static always_inline fuction, though that increases
>> the risk
>> of the compiler messing up...
>> And actually, maybe you could just implement START_TIMER and
>> STOP_TIMER
>> in libavutil (or does that do something else)?
>> If not, maybe naming it START_PROF and END_PROF is at least more
>> consistent, and least the EPROF name is not quite obvious in its
>> meaning
>
>
> In case you didn't know Marc (I'm sure you do though), you only need
> to implement BlackFin version of read_time(void) as found in
> libavutil/common.h to get a working support of START_TIMER and
> STOP_TIMER on you plateform.
I was just reading that as you sent the mail, Does it have to be 64
bits or will 32 bit resolution be fine?
Marc
More information about the ffmpeg-devel
mailing list