Displaying 6 results from an estimated 6 matches for "gpu_device".
2011 Dec 13
2
[LLVMdev] Changes to the PTX calling conventions
...don't see any reason why a generic calling convention would not work. We could do something like cl_device/cl_kernel. I hate to introduce OpenCL terms into a back-end where OpenCL is just one consumer, but it does map cleanly to the architecture model. Or perhaps something more generic like gpu_device/gpu_global.
[Villmow, Micah] Yeah, but this should apply to more than just gpu's. For example, AMD's OpenCL CPU implementation could utilize the calling conventions, along with projects like ocelot that have the device-only vs host/device differentiation. Maybe just device/host is good enou...
2011 Dec 13
0
[LLVMdev] Changes to the PTX calling conventions
...don't see any reason why a generic calling convention would not work. We
could do something like cl_device/cl_kernel. I hate to introduce OpenCL
terms into a back-end where OpenCL is just one consumer, but it does map
cleanly to the architecture model. Or perhaps something more generic like
gpu_device/gpu_global.
> ****
>
> ** **
>
> Thanks,****
>
> Micah****
>
> ** **
>
> ** **
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mai...
2011 Dec 13
2
[LLVMdev] Changes to the PTX calling conventions
Currently, PTX has its own calling conventions where they are split into kernel/device.
The AMDIL backend requires very similar calling conventions and I was wondering if
we could change the calling conventions from PTX_* to something more generic?
Maybe just Kernel/Device? Or would it be preferable to add a new calling convention
that is unique for each target, even though it duplicates
2011 Dec 13
0
[LLVMdev] Changes to the PTX calling conventions
...eason why a generic calling convention would not work.
> We could do something like cl_device/cl_kernel. I hate to introduce
> OpenCL terms into a back-end where OpenCL is just one consumer, but it does
> map cleanly to the architecture model. Or perhaps something more generic
> like gpu_device/gpu_global.****
>
> *[Villmow, Micah] Yeah, but this should apply to more than just gpu's.
> For example, AMD's OpenCL CPU implementation could utilize the calling
> conventions, along with projects like ocelot that have the device-only vs
> host/device differentiation. Maybe...
2011 Dec 13
3
[LLVMdev] Changes to the PTX calling conventions
...don't see any reason why a generic calling convention would not work. We could do something like cl_device/cl_kernel. I hate to introduce OpenCL terms into a back-end where OpenCL is just one consumer, but it does map cleanly to the architecture model. Or perhaps something more generic like gpu_device/gpu_global.
[Villmow, Micah] Yeah, but this should apply to more than just gpu's. For example, AMD's OpenCL CPU implementation could utilize the calling conventions, along with projects like ocelot that have the device-only vs host/device differentiation. Maybe just device/host is good enou...
2011 Dec 13
0
[LLVMdev] Changes to the PTX calling conventions
...eason why a generic calling convention would not work.
> We could do something like cl_device/cl_kernel. I hate to introduce
> OpenCL terms into a back-end where OpenCL is just one consumer, but it does
> map cleanly to the architecture model. Or perhaps something more generic
> like gpu_device/gpu_global.****
>
> *[Villmow, Micah] Yeah, but this should apply to more than just gpu's.
> For example, AMD's OpenCL CPU implementation could utilize the calling
> conventions, along with projects like ocelot that have the device-only vs
> host/device differentiation. Maybe...