[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120710025644.GE5020@openwall.com>
Date: Tue, 10 Jul 2012 06:56:44 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bf_kernel.cl
Sayantan,
I suggested:
> >> I'd try setting WORK_GROUP_SIZE to 12, keep the declaration of S_Buffer
> >> at its current size - introduce some new macro for this, like
> >> LDS_GROUP_SIZE, which we'd keep at 8 for 7970. If lid is <
> >> LDS_GROUP_SIZE, then use the current code. If lid is >= LDS_GROUP_SIZE
> >> (would be 8, 9, 10, or 11 under this example), then use new code that
> >> would use global memory instead (just modify the supplied BF_current_S
> >> directly?)
On Mon, Jul 09, 2012 at 10:55:08PM +0530, Sayantan Datta wrote:
> I think this is not a good idea because because all of the 12 work items in
> a work group would be executed on a single SIMD
Oh, in that case of course it is not.
> Here's my plan:
> Let us assume that each work-item using LDS consume T seconds time.
> Also assume each work-item using Glbal Memory uses xT seconds. Where x is
> unkown to be determined by experiments.
> Keep work group size 8 as before.
> Scheduling the work items like this:
> [(16LDS work items + 16GDS work items)X 32 + (x-1)(16LDS items)X 32] X
> MULTIPLIER
Makes sense.
Thanks,
Alexander
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.
