[Libclc-dev] [PATCH 2/2] amdgcn--mesa3d: Implement get_num_groups()

Jan Vesely via Libclc-dev libclc-dev at lists.llvm.org
Tue Aug 2 08:37:40 PDT 2016


On Tue, 2016-07-26 at 09:36 -0700, Matt Arsenault wrote:
> > 
> > On Jul 26, 2016, at 08:08, Jan Vesely via Libclc-dev <libclc-dev at li
> > sts.llvm.org> wrote:
> > 
> > > 
> > > > 
> > > > 
> > > > I planned to switch r600 to reading these (and global size and
> > > > local
> > > > size) from implicitarg ptr. Is there an advantage to gcn
> > > > reading
> > > > this
> > > > from dispatch info, rather than implicitarg ptr?
> > > > 
> > > 
> > > These intrinsics read these values from the user SGPRs and not
> > > the
> > > dispatch info.  This is really the only difference between what
> > > Mesa
> > > does and what HSA does.
> > 
> > The questions are mostly out of my curiosity, I can't really
> > comment on
> > HSA patches.
> > I take it SGPRs are faster?
> > If these intrinsics follow HSA ABI shouldn't they be in amdgcn-
> > amdhsa
> > directory?
> > The first patch introduced amdgcn-mesa3d directory, but if
> > mesa/clover
> > is switched to use HSA ABI shouldn't libclc produced for amdgcn-
> > amdhsa
> > work for clover as well?
> > 
> > thanks,
> > Jan
> 
> These are defined in the HSA ABI, but are never actually used since
> they are not really implemented in the microcode. They also introduce
> the possibility of using more user SGPRs than the maximum of 16

I'm not sure what this implies. does gcn hw need fw update to use this?
the rest of the questions still remain.
why --mesa3d directory if it should use the same ABI as HSA?
is it more beneficial for gcn clover to share code with r600 clover or
gcn hsa?

Jan

> 
> -Matt
-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/libclc-dev/attachments/20160802/aca01b5a/attachment.sig>


More information about the Libclc-dev mailing list