[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130611035541.GA20994@openwall.com>
Date: Tue, 11 Jun 2013 07:55:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] Low-level GPU programming
Lukas, Daniel -
On Sat, Jun 08, 2013 at 02:43:21PM +0200, Lukas Odzioba wrote:
> Alexander, Daniel:
> we need to discuss in more details:
> -what is the objective of Daniel's gsoc project
For JtR, the objective is to speedup some formats, for which we believe
we're hit by OpenCL limitations the most. These are des-opencl (need
runtime code patching), maybe bf-opencl, maybe SHA-512 stuff.
However, rather than start by trying to produce code for those formats,
we could start by producing simpler pieces of GCN ISA code for testing
and an assembler to generate GCN ISA code.
Alternatively or additionally to generating GCN ISA code from our own
assembly-like source, for des-opencl we could work on runtime patching
of OpenCL-generated ISA code (we only need to patch displacements in the
load instructions based on the current salt value).
Speaking of the source language for generating GCN ISA code from, we're
mostly interested in having an assembler or maybe just slightly higher
level language (such as structured assembly - with if/else, loops, etc
to reduce the need for explicit updates of the exec masks, and for
conditional branches and labels). Maybe something along the lines of
qhasm and qhasm-cudasm, but supporting GCN.
> -what is to be done
Some/all of the above.
> -what are the next steps
I think the immediate next steps could be generating simple GCN ISA
code, using just a handful of different instruction types. Figuring out
the right prologue/epilogue of the kernel. Patching all of this into
existing dummy binary kernel (with sufficient space pre-allocated, so
that we avoid having to mess with ELF headers). Figuring out the
parallel execution model and what flexibility we (don't) have over it.
> After that we can improve the timeline for this project.
Yes, please propose a better timeline.
Also, the project description at
http://www.google-melange.com/gsoc/project/google/gsoc2013/plaintext/28001
needs to be edited. Right now it shows a lack of understanding on
Daniel's part of what we call "slow hashes" (and thus of what we call
"fast hashes" too). Lukas, perhaps you can explain this to Daniel on
IRC or in here?
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.
