Displaying 6 results from an estimated 6 matches for "cl_devic".
Did you mean:
cl_device
2011 Dec 13
2
[LLVMdev] Changes to the PTX calling conventions
...rom 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 functionality?
I 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, A...
2011 Dec 13
0
[LLVMdev] Changes to the PTX calling conventions
...ice? Or would it be preferable to add a new calling
> convention****
>
> that is unique for each target, even though it duplicates functionality?**
> **
>
> ** **
>
> I 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...
2011 Dec 13
3
[LLVMdev] Changes to the PTX calling conventions
...rom 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 functionality?
I 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, A...
2011 Dec 13
0
[LLVMdev] Changes to the PTX calling conventions
...**
>
> 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 functionality?
>
I 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****
>
> ** **
&g...
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
...ice? Or would it be preferable to add a new calling
> convention****
>
> that is unique for each target, even though it duplicates functionality?**
> **
>
> ****
>
> I 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...