I have a toolchain I am trying to build directfb with and I keep getting an error where the config.h is missing. I was wondering if somehow it was find the config.h on my box.
Craig On Thursday 26 March 2009 3:24:19 am vince wrote: > Craig, > > It would be the main config.h generated by 'configure'. It is used to > disable the routine in big-endian mode. > > Vince > > On Wed, 2009-03-25 at 17:39 -0600, Craig Matsuura wrote: > > Which config.h are you refering to in the armasm_memcpy.S? > > > > > > > > Craig > > > > On Wednesday 25 March 2009 12:55:07 pm Craig Matsuura wrote: > > > I took the new armasm memcpy patch and applied it to my > > > > DirectFB-1.1.1 and > > > > > ran it on my davinci based system using gcc-3.4 and real libc. And > > > > it is > > > > > now faster than the libc. Nice job, the original patch actually > > > > slowed > > > > > things down. > > > > > > Thank, > > > Craig > > > > > > On Wednesday 25 March 2009 2:50:35 am vince wrote: > > > > Niels, > > > > > > > > Here is a new version of the patch with the second version of > > > > memcpy and > > > > > > a conditional to remove big-endian. > > > > > > > > Let me know if you have any trouble with it. > > > > > > > > Regards, > > > > > > > > Vince > > > > > > > > On Tue, 2009-03-24 at 16:36 +0100, Niels Roest wrote: > > > > > Hi John, > > > > > thanks for the comments, > > > > > just want to mention 1 or 2 things too. > > > > > > > > > > The testing routines do have a single cold, unmeasured, run > > > > first to > > > > > > > rule out previous cache state influence. > > > > > > > > > > The test itself is in fact really simple - a continuous copy of > > > > a large > > > > > > > region. So no repeats. This does focus on the use case that is > > > > most > > > > > > > obvious for DirectFB, namely copying chunks and lines of > > > > graphics > > > > > > > between surfaces, which will normally lead to cache misses > > > > anyway. I am > > > > > > > most concerned about alignment, since this is really > > > > unpredictable. > > > > > > > I am not sure if we will benefit much from shuffling the code or > > > > using > > > > > > > different memory regions; you have to remember that the testing > > > > > routines produce a single score only, so these will need to be > > > > fine > > > > > > > tuned a lot, and we may even need to revert to multiple memcpy > > > > routines > > > > > > > which are optimised for multiple use cases. This might be an > > > > > interesting approach, it is one I will follow if performance > > > > > measurements show that we can expect a proper benefit from this > > > > - > > > > > > > forgetting that DirectFB is mainly about hardware acceleration > > > > anyway. > > > > > > > For me I am very happy with the changes that Vince made, thanks > > > > Vince, > > > > > > > and if I have a BE/LE lock, I will include the patch. > > > > > > > > > > Greets > > > > > Niels > > > > > > > > > > John Williams wrote: > > > > > > Hi Vince, > > > > > > > > > > > > On Wed, Mar 25, 2009 at 12:57 AM, vince <vi...@bluush.com> > > > > wrote: > > > > > >> Ive change my benchmark to invalidate the cache before every > > > > test. > > > > > > > >> My result are the same. Attached is my test program. > > > > > > > > > > > > No worries - just wanted to make sure we weren't missing the > > > > obvious! > > > > > > > > Might also be worth shuffling the sequencing of the tests > > > > (armasm, > > > > > > > > armasm2, libc), see if that has any impact. I'm not intimate > > > > with > > > > > > > > ARM cache details, but with a write-back cache you could be > > > > stalling > > > > > > > > on cacheline evictions later in the test. > > > > > > > > > > > > Another safety would be to perform the tests in different > > > > memory > > > > > > > > regions, with a complete cache flush and invalidate between > > > > each run. > > > > > > > > Not saying there's anything wrong with your code, just know > > > > its easy > > > > > > > > to get false results from simple benchmark code. Memory tests > > > > are > > > > > > > > another one where the obvious approach is often wrong. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > John > > > > > > _______________________________________________ > > > > > > directfb-dev mailing list > > > > > > directfb-dev@directfb.org > > > > > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > > -- > > > > > > > > > > > > ______________________________________________________________________ > > > > > > Craig Matsuura - Principal Engineer > > > > Control4 > > 11734 South Election Road - Suite 200 > > Salt Lake City, UT 84020-6432 > > PH: 801-523-3161 > > FX: 801-523-3199 -- Craig Matsuura - Principal Engineer Control4 11734 South Election Road - Suite 200 Salt Lake City, UT 84020-6432 PH: 801-523-3161 FX: 801-523-3199
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
