Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 18:52:30 +0530
From: Sayantan Datta <>
Subject: Re: GCN: indexed access to VGPRs

Hi Milen,Solar,

On Sun, Dec 9, 2012 at 6:08 PM, Milen Rangelov <> wrote:

> I thought about that when doing the bcrypt kernel. There is one problem
> with that though - we have a hard limit of 256 VGPRs per workitem and it
> does not matter how many workitems per group we spawn, the limit stays even
> if we run the kernel with worksize of say just 2 items (effectively that
> means we'd underuse the register file a lot). So we can utilize at most 1KB
> of registers for our sbox data. What eventually happens though is that the
> compiler spills registers into global memory (and this register spill is
> much worse than I expected). I tried having one of the 4 sboxes as a
> private array and got a lot of spilled registers, the end result being
> slower even given the increased occupancy and finally for some reason the
> kernel was not calculating the hash correctly (might be mistake on my part
> or a compiler issue, didn't investigate).

Yes I think the limit is 256 VGPRs per wavefront. Now wavefront size is
maximum of 64 for GCN given that the resources are plenty for 64 work
items. In case of bcrypt the wavefront size is much less if we are using
LDS or trying private arrays for Sbox.

 Each 512 bit VGPR can hold 16 32bit ints. By indexed access to VGPRs ,
I think he(solar) means each component of a VGPR can be indexed, right ? Or
is it that the 256 different VGPRs can be indexed, not their individual
components? Although the later would make more sense given that they are


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.