Beignet wants to apply libclc

Runtimes OpenCL
#1

hi,

I am a developer of Intel's open source CL stack, which name is Beignet.
We used to include all the CL built-ins in one huge header file and
compile it as a PCH.
We find some disadvantages of that manner and switched to the same
manner as libclc recently. We now have a internal lib, which play the
same role as the libclc, and we are attempting to apply the libclc to
replace it in the near future.
But I find some problems when I try to integrate the libclc:
1. There is no support for Image related functions in it now. Is that on
your plan?
2. I find it is not compatible with OpenCL1.2, which Beignet must
support, are you going to implement it?
3. Because beignet as a backend does not completely follow the PTX or
NVPTX framework, it has a lot of internal implementations for the
builtin functions. We may need to add a lot of files for it, is that
acceptable?

Thanks

#2

He Junyan

The pocl project <http://pocl.sourceforge.net/> also contains an
implementation of the OpenCL run-time library, and I was similarly
hoping that we could join forces with libclc at some point.

Compared to libclc, pocl should have more functionality, but the math
functions are optimized for speed instead of accuracy.

-erik

#3

hi,

I am a developer of Intel's open source CL stack, which name is Beignet.
We used to include all the CL built-ins in one huge header file and
compile it as a PCH.
We find some disadvantages of that manner and switched to the same
manner as libclc recently. We now have a internal lib, which play the
same role as the libclc, and we are attempting to apply the libclc to
replace it in the near future.
But I find some problems when I try to integrate the libclc:
1. There is no support for Image related functions in it now. Is that on
your plan?

libclc only supports GPU targets and these targets require target-specific
implementations of the image functions, which is why there are no
generic image functions. If you were to use libclc for Intel GPUs, you
would need to implement your own target specific image functions.

2. I find it is not compatible with OpenCL1.2, which Beignet must
support, are you going to implement it?

In what way is it not compatible? The goal is to implement everything,
but as far as I know no one has spent much time on OpenCL 1.2 features.

3. Because beignet as a backend does not completely follow the PTX or
NVPTX framework, it has a lot of internal implementations for the
builtin functions. We may need to add a lot of files for it, is that
acceptable?

Yes, if you are adding a new target with a lot of target specific
implementations, then it is not a problem if there are a lot of files.

-Tom

#4

He Junyan

The pocl project <http://pocl.sourceforge.net/> also contains an
implementation of the OpenCL run-time library, and I was similarly
hoping that we could join forces with libclc at some point.

This would be great if we could do this.

Compared to libclc, pocl should have more functionality, but the math
functions are optimized for speed instead of accuracy.

I'm not sure pocl has more functionality than libclc when it comes to
GPUs. pocl uses __builtin functions for a lot of the math intrinsics which
expand to libm calls, but libm is not available on GPUs.

-Tom

#5

He Junyan

The pocl project <http://pocl.sourceforge.net/> also contains an
implementation of the OpenCL run-time library, and I was similarly
hoping that we could join forces with libclc at some point.

This would be great if we could do this.

I have been following the recent additions to libclc adding
high-accuracy math functions; this is where pocl's clc library is
lacking. While all math functions should be there, they often do not
have the required accuracies.

Compared to libclc, pocl should have more functionality, but the math
functions are optimized for speed instead of accuracy.

I'm not sure pocl has more functionality than libclc when it comes to
GPUs. pocl uses __builtin functions for a lot of the math intrinsics which
expand to libm calls, but libm is not available on GPUs.

Apologies -- I indeed meant for CPUs. To my knowledge, pocl has not
been used to target GPUs, although other accelerator-type devices are
targeted as well.

-erik

#6

The beignet is a OpenCL driver only for Intel's GEN GPU.
According to this, I am sorry that we have to remove the pocl
from our candidate list.

#7

> hi,
>
> I am a developer of Intel's open source CL stack, which name is Beignet.
> We used to include all the CL built-ins in one huge header file and
> compile it as a PCH.
> We find some disadvantages of that manner and switched to the same
> manner as libclc recently. We now have a internal lib, which play the
> same role as the libclc, and we are attempting to apply the libclc to
> replace it in the near future.
> But I find some problems when I try to integrate the libclc:
> 1. There is no support for Image related functions in it now. Is that on
> your plan?

libclc only supports GPU targets and these targets require target-specific
implementations of the image functions, which is why there are no
generic image functions. If you were to use libclc for Intel GPUs, you
would need to implement your own target specific image functions.

OK, get it. The image module is really specific for each vendor and some
of them do not want to expose the HW details to the public.

> 2. I find it is not compatible with OpenCL1.2, which Beignet must
> support, are you going to implement it?

In what way is it not compatible? The goal is to implement everything,
but as far as I know no one has spent much time on OpenCL 1.2 features.

The beignet has declared the full support for 1.2, but if we use clc, we
have to fallback to 1.1, this seems weird.
So far as I know, there are really some changes for CL APIs between 1.1
and 1.2, but for the builtin functions and defines, the changes are not
so big. The major changes are: adding 1d image and sampler-less image
read functions, adding printf function, and adding extern and static
keyword support. And the image module is even not included in clc, so I
think this is not a big task to support 1.2, and I can do that job if
you do not mind.

> 3. Because beignet as a backend does not completely follow the PTX or
> NVPTX framework, it has a lot of internal implementations for the
> builtin functions. We may need to add a lot of files for it, is that
> acceptable?

Yes, if you are adding a new target with a lot of target specific
implementations, then it is not a problem if there are a lot of files.

OK, I will consider how to integrate our implementation and maximize the
use of the clc's code.

#8

> hi,
>
> I am a developer of Intel's open source CL stack, which name is Beignet.
> We used to include all the CL built-ins in one huge header file and
> compile it as a PCH.
> We find some disadvantages of that manner and switched to the same
> manner as libclc recently. We now have a internal lib, which play the
> same role as the libclc, and we are attempting to apply the libclc to
> replace it in the near future.
> But I find some problems when I try to integrate the libclc:
> 1. There is no support for Image related functions in it now. Is that on
> your plan?

libclc only supports GPU targets and these targets require target-specific
implementations of the image functions, which is why there are no
generic image functions. If you were to use libclc for Intel GPUs, you
would need to implement your own target specific image functions.

OK, get it. The image module is really specific for each vendor and some
of them do not want to expose the HW details to the public.

> 2. I find it is not compatible with OpenCL1.2, which Beignet must
> support, are you going to implement it?

In what way is it not compatible? The goal is to implement everything,
but as far as I know no one has spent much time on OpenCL 1.2 features.

The beignet has declared the full support for 1.2, but if we use clc, we
have to fallback to 1.1, this seems weird.
So far as I know, there are really some changes for CL APIs between 1.1
and 1.2, but for the builtin functions and defines, the changes are not
so big. The major changes are: adding 1d image and sampler-less image
read functions, adding printf function, and adding extern and static
keyword support. And the image module is even not included in clc, so I
think this is not a big task to support 1.2, and I can do that job if
you do not mind.

Also, I believe that the only non-image built-in function that was
added is popcount, which we don't support yet. I think it would be
easy to add, but it hasn't been added yet due to time constraints.

I'm not quite sure if anything has to be done for extern/static
besides enabling the clang extension
cl_clang_storage_class_specifiers. For R600/Clover, I believe that
we're just not enabling it correctly (we're defining the macro but not
enabling the extension in the CL source), but I haven't been able to
finish the code to test that.. It's possible that beignet may be able
to do something similar.

--Aaron

#9

> > hi,
> >
> > I am a developer of Intel's open source CL stack, which name is Beignet.
> > We used to include all the CL built-ins in one huge header file and
> > compile it as a PCH.
> > We find some disadvantages of that manner and switched to the same
> > manner as libclc recently. We now have a internal lib, which play the
> > same role as the libclc, and we are attempting to apply the libclc to
> > replace it in the near future.
> > But I find some problems when I try to integrate the libclc:
> > 1. There is no support for Image related functions in it now. Is that on
> > your plan?
>
> libclc only supports GPU targets and these targets require target-specific
> implementations of the image functions, which is why there are no
> generic image functions. If you were to use libclc for Intel GPUs, you
> would need to implement your own target specific image functions.
>
OK, get it. The image module is really specific for each vendor and some
of them do not want to expose the HW details to the public.

In the case of AMD, it's not because we don't want to expose HW details.
We have already done this. It's just that no one has had time to
implement the builtins yet.

> > 2. I find it is not compatible with OpenCL1.2, which Beignet must
> > support, are you going to implement it?
>
> In what way is it not compatible? The goal is to implement everything,
> but as far as I know no one has spent much time on OpenCL 1.2 features.
>
The beignet has declared the full support for 1.2, but if we use clc, we
have to fallback to 1.1, this seems weird.
So far as I know, there are really some changes for CL APIs between 1.1
and 1.2, but for the builtin functions and defines, the changes are not
so big. The major changes are: adding 1d image and sampler-less image
read functions, adding printf function, and adding extern and static
keyword support. And the image module is even not included in clc, so I
think this is not a big task to support 1.2, and I can do that job if
you do not mind.

Feel free to add any 1.2 features to libclc that you want. As you say, I
don't think there are many changes in the builtin library from 1.1 to 1.2.

As for extern and static, this is handled by clang and not libclc. If you
pass -cl-std=CL1.2 to clang, it should automatically enable these features.

-Tom

#10

>
> > > hi,
> > >
> > > I am a developer of Intel's open source CL stack, which name is Beignet.
> > > We used to include all the CL built-ins in one huge header file and
> > > compile it as a PCH.
> > > We find some disadvantages of that manner and switched to the same
> > > manner as libclc recently. We now have a internal lib, which play the
> > > same role as the libclc, and we are attempting to apply the libclc to
> > > replace it in the near future.
> > > But I find some problems when I try to integrate the libclc:
> > > 1. There is no support for Image related functions in it now. Is that on
> > > your plan?
> >
> > libclc only supports GPU targets and these targets require target-specific
> > implementations of the image functions, which is why there are no
> > generic image functions. If you were to use libclc for Intel GPUs, you
> > would need to implement your own target specific image functions.
> >
> OK, get it. The image module is really specific for each vendor and some
> of them do not want to expose the HW details to the public.
>

In the case of AMD, it's not because we don't want to expose HW details.
We have already done this. It's just that no one has had time to
implement the builtins yet.

> > > 2. I find it is not compatible with OpenCL1.2, which Beignet must
> > > support, are you going to implement it?
> >
> > In what way is it not compatible? The goal is to implement everything,
> > but as far as I know no one has spent much time on OpenCL 1.2 features.
> >
> The beignet has declared the full support for 1.2, but if we use clc, we
> have to fallback to 1.1, this seems weird.
> So far as I know, there are really some changes for CL APIs between 1.1
> and 1.2, but for the builtin functions and defines, the changes are not
> so big. The major changes are: adding 1d image and sampler-less image
> read functions, adding printf function, and adding extern and static
> keyword support. And the image module is even not included in clc, so I
> think this is not a big task to support 1.2, and I can do that job if
> you do not mind.
>

Feel free to add any 1.2 features to libclc that you want. As you say, I
don't think there are many changes in the builtin library from 1.1 to 1.2.

As for extern and static, this is handled by clang and not libclc. If you
pass -cl-std=CL1.2 to clang, it should automatically enable these features.

really true, new clang version has supported it and I just found it
recently.

I now get it and will try to integrate intel's implementation into CLC

thanks for your information.