[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27446e3af6c8a9ef33f8e05c577b70ea@smtp.hushmail.com>
Date: Tue, 12 Jun 2012 21:30:48 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: OS_TIMER and AMD SDK
On 2012-04-04 01:03, magnum wrote:
> On 04/03/2012 01:19 PM, Solar Designer wrote:
>> On Tue, Apr 03, 2012 at 08:54:31AM +0200, magnum wrote:
>>> [...] I'll commit it. I will leave out the
>>> OSTIMER change in x86-sse.h for now though, it's not universal. Or
>>> perhaps we should universally set it to 0 until we get something better?
>>> Solar?
>>
>> As I wrote in:
>>
>> http://www.openwall.com/lists/john-dev/2012/04/02/25
>>
>> "... change that to only set OS_TIMER to 0 when
>> building with OpenCL support with AMD SDK specifically (since OS_TIMER 1
>> is preferable when we can have it), but to do it from both header files."
>
> Yes but I am not sure how to best detect that. I will try this for now:
> Since we already have ifdef...endif's in Makefile, I will use them to
> -DAMDAPP which in turn can be used in arch.h's. But this will affect any
> OpenCL build even if not currently *using* AMD, but just having it
> installed (like I do, to occasionally try AMD's OpenCL on CPU).
When using latest Ubuntu 12 with the distributions' AMD drivers, we get
neither AMDAPPSDKROOT nor ATISTREAMSDKROOT from the environment so
OS_TIMER does not get set to 0, and indeed we get the semaphore_wait
problems.
I have no idea how to fix this other than having all OpenCL builds set
OS_TIMER=0.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
