Quote from: pallas on July 15, 2015, 06:20:30 AM

Quote from: jk_14 on July 14, 2015, 10:10:32 PM

Quote from: pallas on July 14, 2015, 07:52:16 PM

Almost all the kernel time is spent on the lyra part (which is essentially Blake on a bigger internal structure). It is slow because it doesn't fit in the registers nor in local ram; and the access is random, not sequential.
So if you want to make it GPU friendly, the only way is removing the "lyra" from "lyra2re". What remains is something similar to a subset of x11.

maybe is the time for worldwide contest for GPU oriented algo, with significant sequential memory access, utilising minimum 1GB memory.

so let's get back to scrypt-n? LoL!

1. Generate 1GB PsuedoRandom data using SHA512.

  2. For each 64K block - Repeat 50 times.
   2.1 Use the last 32bits as a pointer to another 64K block.
   2.2 XOR the two 64K blocks together.
   2.3 AES CBC encrypt the result using the last 256 bits as a key.

  3. Use the last 32bits%2^14 as the solution. If the solution==1968, the block is solved.

https://bitcointalk.org/index.php?topic=598187.0

maybe some tuning of this, for more sequential access
maybe much greater block size, maybe not AES CBC but CTR - for strong parallelisation.

?