[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUBXvvP+_xuWxCgoPu1i-ZJadg=m+W-CW_gw3MrUY2Hv7Q@mail.gmail.com>
Date: Sat, 11 May 2013 20:40:04 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: AMD GCN ISA development
Hi Solar,
On Fri, May 10, 2013 at 10:57 AM, Solar Designer <solar@...nwall.com> wrote:
> Sayantan, Daniel -
>
> On Sun, Apr 28, 2013 at 09:43:51PM +0200, D?niel Bali wrote:
> > I started looking into AMD's GCN ISA architecture a couple of days ago,
> but
> > I still can't find much info about getting started with it and I have a
> > couple of questions. I found this:
> > http://openwall.info/wiki/john/development/AMD-IL
> >
> > Which describes how to write AMD IL code, but I was wondering if this
> works
> > for GCN ISA. Does anybody have experience with this? (Or with GCN ISA
> > development in general?)
>
> I've just tried:
>
> rm kernels/bf_kernel_Tahiti.bin
> AMD_OCL_BUILD_OPTIONS_APPEND=-save-temps ./john -te -form=bf-opencl -pla=1
>
> which generated:
>
> $ wc -lc _temp_0_tahiti*
> 255 7080 _temp_0_tahiti.cl
> 17129 492658 _temp_0_tahiti.il
> 17104 492186 _temp_0_tahiti_blowfish.il
> 840 67772 _temp_0_tahiti_blowfish.isa
>
> It is curious (and very nice) how the .isa file is actually much smaller
> than the .il. Only 840 lines. Also, it contains offsets and raw
> opcodes as comments - so it should be easy to find the corresponding
> places in the binary (such as for des-opencl, where we're considering
> runtime patching of the binary). I've just tried:
>
> $ fgrep -i 7E06021D *.isa
> v_mov_b32 v3, s29 // 00000038:
> 7E06021D
> v_mov_b32 v3, s29 // 000000E4:
> 7E06021D
> v_mov_b32 v3, s29 // 00000190:
> 7E06021D
> [...]
> v_mov_b32 v3, s29 // 00000D28:
> 7E06021D
> v_mov_b32 v3, s29 // 00000DD8:
> 7E06021D
> v_mov_b32 v3, s29 // 00000E88:
> 7E06021D
>
> $ od -tx1 kernels/bf_kernel_Tahiti.bin | fgrep '1d 02 06 7e'
> 3031600 00 00 82 08 04 34 1d 02 06 7e 82 02 08 38 00 00
> 3032060 04 34 1d 02 06 7e 82 08 0a 38 00 00 34 d8 02 03
> 3032600 34 d8 02 03 00 00 82 0a 04 34 1d 02 06 7e 82 08
> [...]
> 3105100 00 00 82 10 04 34 1d 02 06 7e 82 0a 10 38 00 00
> 3105660 00 00 82 10 04 34 1d 02 06 7e 82 0a 10 38 00 00
> 3107040 34 d8 02 03 00 00 82 0a 04 34 1d 02 06 7e 82 08
>
> Curiously, these are not at aligned addresses in the binary kernel file,
> so I could not use "od -tx4", but that's no problem.
>
> Daniel - did you get at least this far in your experiments by now?
>
> Daniel, Sayantan, all - have you figured out how we may generate a
> kernel binary from the .isa file (possibly after modifying it)?
>
> Alexander
>
I am currently working with binary des kernels. For now I'm only able
compress the binary kernels from 378KB to 14.8KB but I still have some more
work to do. I'm targeting an average of less than 10KB per kernel, which
will be around 40MB for all 4096 kernels. Perhaps we might be able to
distribute them separately.
However in the process I have learn a lot about binary opencl objects. The
true executable binary is an elf object inside the primary elf object.
Apparently GCN isa is only a very small portion of the inner elf. Along
with isa there are a lot of other data sections which is kind of
incompressible.
Yes it is possible to modify the isa but it will require some adjustment to
both inner and outer elf(which I haven't figured out but should be
possible). Although we can modify/replace the instructions of same size
right away.
Regards,
Sayantan
Content of type "text/html" skipped
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.
