llvm dev - Mar 2012 - [LLVMdev] GPU thread/block/grid size contraints in LLVM PTX backend

but does it have default values ?

Thanks

Xin

On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at gmail.com>
wrote:
> You specify shader model, bit size and etc. arch-specified parameters
> though -march, -mattr and -mcpu, but AFAIK, PTX backend does not use
> the GPU thread/block/grid size information in optimization yet.
>
> On Mon, Mar 12, 2012 at 8:17 PM, Xin Tong <xerox.time.tech at
gmail.com> wrote:
>> I am wondering that how does the LLVM PTX backend find out the
>> constraints on executing GPU thread/block/grid size ( i.e. a block can
>> at most have 1024 threads). Can anyone point me to the code ? I need
>> information in the optimizer,  how can I get it ?
>>
>> Thanks
>>
>> Xin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

I don't think so, but you should check source code.

On Tue, Mar 13, 2012 at 9:58 PM, Xin Tong <xerox.time.tech at gmail.com>
wrote:
> but does it have default values ?
>
> Thanks
>
> Xin
>
> On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at
gmail.com> wrote:
>> You specify shader model, bit size and etc. arch-specified parameters
>> though -march, -mattr and -mcpu, but AFAIK, PTX backend does not use
>> the GPU thread/block/grid size information in optimization yet.
>>
>> On Mon, Mar 12, 2012 at 8:17 PM, Xin Tong <xerox.time.tech at
gmail.com> wrote:
>>> I am wondering that how does the LLVM PTX backend find out the
>>> constraints on executing GPU thread/block/grid size ( i.e. a block
can
>>> at most have 1024 threads). Can anyone point me to the code ? I
need
>>> information in the optimizer,  how can I get it ?
>>>
>>> Thanks
>>>
>>> Xin
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

The backend currently does not carry any information like this explicitly.
 The goal is to represent a single thread in LLVM IR, and generate the
appropriate thread-level PTX code.  At that level, the number of threads
per block and blocks per grid is irrelevant.  If you need that information,
you're better off feeding it directly into your compiler/optimizer.  We can
(and should) carry around explicitly stated block size constraints
representable in PTX, but that's a bit different.

On Thu, Mar 15, 2012 at 2:47 AM, Che-Liang Chiou <clchiou at gmail.com>
wrote:
> I don't think so, but you should check source code.
>
> On Tue, Mar 13, 2012 at 9:58 PM, Xin Tong <xerox.time.tech at
gmail.com>
> wrote:
> > but does it have default values ?
> >
> > Thanks
> >
> > Xin
> >
> > On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at
gmail.com>
> wrote:
> >> You specify shader model, bit size and etc. arch-specified
parameters
> >> though -march, -mattr and -mcpu, but AFAIK, PTX backend does not
use
> >> the GPU thread/block/grid size information in optimization yet.
> >>
> >> On Mon, Mar 12, 2012 at 8:17 PM, Xin Tong <xerox.time.tech at
gmail.com>
> wrote:
> >>> I am wondering that how does the LLVM PTX backend find out the
> >>> constraints on executing GPU thread/block/grid size ( i.e. a
block can
> >>> at most have 1024 threads). Can anyone point me to the code ?
I need
> >>> information in the optimizer,  how can I get it ?
> >>>
> >>> Thanks
> >>>
> >>> Xin
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120323/0f05e1bb/attachment.html>