FreeBSD OpenCL/CUDA nVidia

[CeDeROM]

Hello world,

Is nVidia OpenCL/CUDA supported on FreeBSD?

I have GF1030GT on 11.2-RELEASE AMD64 using 390.77 nvidia driver.
CLINFO shows 0 number of platforms :-(

Any hints welcome :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Tommi Pernila]

Hi,

Nvidia doesn't provide native CUDA drivers.

There might be an option on trying to run the driver through the
linuxulator, but it looks like it there are some issue with it.

this thread has a bit more information:
https://forums.freebsd.org/threads/linux-binary-compatibility-nvidia-drivers-and-cuda-for-blender.65065/

So it looks like FreeBSD is not the platform for CUDA.
OpenCL with AMD and Intel should be working with FreeBSD.

-T

On Sat, 1 Sep 2018 at 1.55, CeDeROM <ced...@tlen.pl> wrote:

> Hello world,
>
> Is nVidia OpenCL/CUDA supported on FreeBSD?
>
> I have GF1030GT on 11.2-RELEASE AMD64 using 390.77 nvidia driver.
> CLINFO shows 0 number of platforms :-(
>
> Any hints welcome :-)
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> _______________________________________________

> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[CeDeROM]

Thank you Tommy.. bad news.. how did that happen for nVidia to become
worst GPU driver provider to FreeBSD lagging even behind ATI/AMD and
Intel.. I guess these are closed-source drivers so we have nothing to
do here.. I was always buying nVidia only because of trust in their
best drivers.. but that needs to be revised I see :-(

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________

[Carmel NY]

On Sat, 1 Sep 2018 11:44:02 +0200, CeDeROM stated:

>Thank you Tommy.. bad news.. how did that happen for nVidia to become
>worst GPU driver provider to FreeBSD lagging even behind ATI/AMD and
>Intel.. I guess these are closed-source drivers so we have nothing to
>do here.. I was always buying nVidia only because of trust in their
>best drivers.. but that needs to be revised I see :-(
>

I don't believe that is a correct interpretation of the problem. Several
years ago, FreeBSD was unable to support nVidia's 64 bit drivers. Eventually,
that problem was alleviated. However, and this is what I have gathered from
reading chat forums dedicated to nVidia, FreeBSD still does not properly
handle all of the features that nVidia offers in a manner similar to MS
Windows (naturally) and other *.nix operating systems. A business model where
nVidia would be forced to spend large amounts of money to devise a way to be
100% compatible with FreeBSD, a user base magnitudes smaller than MS Windows
or other *.nix operating systems, would prove to be a losing strategy.

A far more easily implemented plan would be for the FreeBSD developers to pin
point exactly what FreeBSD needs to do to become fully compatible with nVidia
products. Microsoft works closely with nVidia, as well as some other *.nix
developers to assure that their products are compatible. Why isn't FreeBSD
taking this approach?

--
Carmel

[CeDeROM]

Great idea! Workplan and TODO list from FreeBSD to nVidia could be really
helpful and productive for both parties :-)

Anyone taking care of X11/nVidia at this point?

How about Open-Source NV driver? Any chance this one could support
CUDA/OpenCL?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

[Steve O'Hara-Smith]

On Sat, 1 Sep 2018 14:54:26 +0000
Carmel NY <carm...@outlook.com> wrote:

> I don't believe that is a correct interpretation of the problem. Several
> years ago, FreeBSD was unable to support nVidia's 64 bit drivers.

You have it backwards - nVidia's drivers come from nVidia they
choose what platforms to write drivers for, how often to update them and
what features to support on each platform. They naturally prioritise the
platforms that lead to the most sales - which would be Windows (several
versions for different versions of Windows) then Linux then FreeBSD.

If memory serves correctly FreeBSD originally supported running
nVidia's 32 bit Linux drivers with the aid of the linux emulation layer. It
was some time before FreeBSD had a 64 bit Linux emulation layer. Nothing to
do with supporting nVidia products, everything to do with supporting Linux
ABIs. Now nVidia provide FreeBSD drivers so there's little incentive to
consider running the Linux drivers under emulation.

> A far more easily implemented plan would be for the FreeBSD developers to
> pin point exactly what FreeBSD needs to do to become fully compatible
> with nVidia products.

nVidia make products for several versions of Windows, Linux and
FreeBSD these drivers are all different and tailored to their targets by
nVidia with the help of the OS makers in each case. There's no such thing
as "fully compatible with nVidia products", it's not as though Windows and
Linux run the same drivers.

--
Steve O'Hara-Smith <st...@sohara.org>

[Valeri Galtsev]

On 9/1/18 9:54 AM, Carmel NY wrote:
> On Sat, 1 Sep 2018 11:44:02 +0200, CeDeROM stated:
>
>> Thank you Tommy.. bad news.. how did that happen for nVidia to become
>> worst GPU driver provider to FreeBSD lagging even behind ATI/AMD and
>> Intel.. I guess these are closed-source drivers so we have nothing to
>> do here.. I was always buying nVidia only because of trust in their
>> best drivers.. but that needs to be revised I see :-(
>>
>
>
> I don't believe that is a correct interpretation of the problem. Several
> years ago, FreeBSD was unable to support nVidia's 64 bit drivers. Eventually,
> that problem was alleviated. However, and this is what I have gathered from
> reading chat forums dedicated to nVidia, FreeBSD still does not properly
> handle all of the features that nVidia offers in a manner similar to MS
> Windows (naturally) and other *.nix operating systems. A business model where
> nVidia would be forced to spend large amounts of money to devise a way to be
> 100% compatible with FreeBSD, a user base magnitudes smaller than MS Windows
> or other *.nix operating systems, would prove to be a losing strategy.

I was holding it off, but you just made me comment on NVIDIA and on what
you said.

You have it all backwards. It is not FreeBSD that doesn't [supports ...
NVIDIA ... features]. It is NVIDIA that does not disclose the internals
of their chips, and it does not disclose any [or at least sufficient]
specifications. In other words, there is no way any programmer will be
able to write driver for NVIDIA chips plainly because of lack of
necessary information.

NVIDIA was like that since forever. It sets me off when someone [of
Linux folks] says "compile NVIDIA driver". It is not NVIDIA driver they
compile, but merely interface between NVIDIA proprietary driver
(available only in binary form) and particular version of [Linux] kernel.

>
> A far more easily implemented plan would be for the FreeBSD developers to pin
> point exactly what FreeBSD needs to do to become fully compatible with nVidia
> products. Microsoft works closely with nVidia, as well as some other *.nix
> developers to assure that their products are compatible. Why isn't FreeBSD
> taking this approach?

Please, get your facts straight! It is NVIDIA that just ignores the
existence of other systems (apart from which they made sure their binary
proprietary driver works on). Do not request open source systems to
become "compatible" with some proprietary hardware which is just a black
box without any description of what is inside (for the whole open source
world).

Also, previous poster of this thread put NVIDIA above Intel and ATI
video chips. I don't care about Intel video chip (which is crap IMHO),
but I feel offended by under-rating ATI. In my observation, for over
decade (maybe a couple of decades) ATI (bought out by AMD a few years
ago) was disclosing sufficient amount of information about internals of
their video chips, therefore open source Linux drivers always worked
well and had access to pretty much all features of ATI video chips. To
the contrary to NVIDIA, for whose chips there was only minimal
information, thus it was possible to write open source driver that
worked only in very generic way (e.g. you could get in trouble using
open source driver for NVIDIA card with dual screen, so you have to
install darn NVIDIA binary driver).

Some Linux folks around me were always setting me off when they were
praising NVIDIA, and saying BS like "compiling NVIDIA driver" whereas it
is merely interface between binary closed source driver and kernel that
they were compiling.

And last but not least. FreeBSD is open source system. Therefore,
demanding that FreeBSD "works with" proprietary software and hardware
developer, is something way out of reasonable. If someone - NVIDIA -
elected not to disclose their information to open source community, no
sane person will invest their time into even develop some open source
software even for some particular hardware for which enough information
is available. It only will be possible if NVIDIA in our case discloses
all information, but even that is not enough, or at least will not be
enough for me, they have to commit to always providing all information,
otherwise tomorrow they may stop doing it and all my today's work goes
to trash.

So, please, put the blame where it belongs: with NVIDIA not supporting
several major open source systems, FreeBSD being one of them.

Valeri


--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

[Valeri Galtsev]

On 9/1/18 10:34 AM, Steve O'Hara-Smith wrote:
> On Sat, 1 Sep 2018 14:54:26 +0000
> Carmel NY <carm...@outlook.com> wrote:
>
>> I don't believe that is a correct interpretation of the problem. Several
>> years ago, FreeBSD was unable to support nVidia's 64 bit drivers.
>
> You have it backwards - nVidia's drivers come from nVidia they
> choose what platforms to write drivers for, how often to update them and
> what features to support on each platform. They naturally prioritise the
> platforms that lead to the most sales - which would be Windows (several
> versions for different versions of Windows) then Linux then FreeBSD.
>
> If memory serves correctly FreeBSD originally supported running
> nVidia's 32 bit Linux drivers with the aid of the linux emulation layer. It
> was some time before FreeBSD had a 64 bit Linux emulation layer. Nothing to
> do with supporting nVidia products, everything to do with supporting Linux
> ABIs. Now nVidia provide FreeBSD drivers so there's little incentive to
> consider running the Linux drivers under emulation.
>
>> A far more easily implemented plan would be for the FreeBSD developers to
>> pin point exactly what FreeBSD needs to do to become fully compatible
>> with nVidia products.
>
> nVidia make products for several versions of Windows, Linux and
> FreeBSD these drivers are all different and tailored to their targets by
> nVidia with the help of the OS makers in each case. There's no such thing
> as "fully compatible with nVidia products", it's not as though Windows and
> Linux run the same drivers.
>

Thanks, Steve, I second that. I didn't see your reply when few seconds
ago I replied with somewhat similar (though much angrier, as wrong
things really set me off) post.

Valeri

--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

[Valeri Galtsev]

On 9/1/18 11:14 AM, CeDeROM wrote:
> Great idea! Workplan and TODO list from FreeBSD to nVidia could be really
> helpful and productive for both parties :-)
>
> Anyone taking care of X11/nVidia at this point?

No, they have always been closed source, no details disclosing folts

>
> How about Open-Source NV driver? Any chance this one could support
> CUDA/OpenCL?

Stop dreaming, this will never happen, NVIDIA has long history of not
disclosing details of their chips internals, and no sane programmer will
waste time on the stuff from company that has longstanding attitude line
NVIDIA's one.

If you program that, I will say hooray, and simultaneously will tell you
my condolences in advance as quite soon your driver will die because of
lack on information from NVIDIA. Which I predict will happen even if you
once get all information you need. This is my (and not only my) loooong
observation.

Valeri

>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>

--
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

[Steve O'Hara-Smith]

On Sat, 1 Sep 2018 18:14:21 +0200
CeDeROM <ced...@tlen.pl> wrote:

> Great idea! Workplan and TODO list from FreeBSD to nVidia could be really
> helpful and productive for both parties :-)
>
> Anyone taking care of X11/nVidia at this point?
>
> How about Open-Source NV driver? Any chance this one could support
> CUDA/OpenCL?

Having taken a look at the nVidia site it seems that the FreeBSD
video driver is probably essentially the same as the Linux one (the
documentation keeps saying Linux), but the CUDA stack is a completely
separate product only available for Windows, Linux and Mac. Possibly the
Linux one might be persuaded to work.

As for OpenCL that would need documentation that nVidia chooses not
to publish.

--
Steve O'Hara-Smith <st...@sohara.org>

[CeDeROM]

On Sat, Sep 1, 2018 at 7:23 PM Valeri Galtsev <gal...@kicp.uchicago.edu> wrote:
> On 9/1/18 11:14 AM, CeDeROM wrote:
> > Great idea! Workplan and TODO list from FreeBSD to nVidia could be really
> > helpful and productive for both parties :-)
> >
> > Anyone taking care of X11/nVidia at this point?
> No, they have always been closed source, no details disclosing folts
>
> >
> > How about Open-Source NV driver? Any chance this one could support
> > CUDA/OpenCL?
>
> Stop dreaming, this will never happen, NVIDIA has long history of not
> disclosing details of their chips internals, and no sane programmer will
> waste time on the stuff from company that has longstanding attitude line
> NVIDIA's one.

Thank you Valeri for this bucket of cold water.

I remember long time ago, when for the first and last time I bought an
ATI card, then I had to rewrite some glue of the binary blob of the
x11 driver when Linux switched from 2.4.9 to 2.4.10 and its internal
API started to change on each kernel release.. that was the time and
reason I have stopped using both ATI and Linux (that I was using since
2.0.36 and I guess that was around FreeBSD 3 era)..

I was so amazed by nVidia support back then, and their FreeBSD driver
even supporting Linux emulation. I was buying and recommending only
nVidia. Things just worked out of the box "the BSD way". UNTIL TODAY
:-(

Looks like coins have flipped and today nVidia lags behind even
simplest cards.. with non-existent specifications and absolutely
minimal support for Open-Source :-(

How sad. World is going bad direction :-(

You know what, if nVidia does not care about its most geeky customers,
I heard OpenCL working on ATI/AMD + FreeBSD.. and I am using OpenCL on
Intel video on my macOS right now.. I will borrow a Radeon and see if
that works out of the box :-)

That would also explain why PlayStation4 that runs on FreeBSD uses
both AMD CPU and GPU. Maybe this is the way to go..

What is the current AMD/ATI support for Open-Source? Do they provide
full GPU specification as opposed to nVidia?

Best regards,
Tomek

[CeDeROM]

On Sat, Sep 1, 2018 at 7:40 PM Steve O'Hara-Smith <st...@sohara.org> wrote:
> > How about Open-Source NV driver? Any chance this one could support
> > CUDA/OpenCL?
>
> Having taken a look at the nVidia site it seems that the FreeBSD
> video driver is probably essentially the same as the Linux one (the
> documentation keeps saying Linux), but the CUDA stack is a completely
> separate product only available for Windows, Linux and Mac. Possibly the
> Linux one might be persuaded to work.
>
> As for OpenCL that would need documentation that nVidia chooses not
> to publish.

Thank you Steve! NVIDIA SUX! Any better with AMD/ATI in the
Open-Source world now?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

[Steve O'Hara-Smith]

On Sat, 1 Sep 2018 23:07:46 +0200
CeDeROM <ced...@tlen.pl> wrote:

> What is the current AMD/ATI support for Open-Source? Do they provide
> full GPU specification as opposed to nVidia?

AMD/ATI opened up their interfaces and some core source code about a
decade ago they still produce a closed source driver of their own but they
support the open source Linux video driver apparently enthusiastically
(according to one report it is now faster than the closed source one).

Both Intel and AMD/ATI provide open source OpenCL stacks

It really is nVidia that is the odd one out - but they do hold the
high end of the hardware, the cards gamers and cryptocurrency miners lust
after are all nVidia.

--
Steve O'Hara-Smith <st...@sohara.org>

[blubee blubeeme]

If you could see the proprietary codebase that some of these companies
ship, you'd understand why they hesitate to open source it.

[cpghost]

On 9/1/18 11:07 PM, CeDeROM wrote:
> What is the current AMD/ATI support for Open-Source? Do they provide
> full GPU specification as opposed to nVidia?

To be frank: not that good either. I have an RX 580 running amdgpu open
source driver. Xorg and OpenGL support is supperb. But OpenCL sucks big way.

There is clover, the open source OpenCL implemention of Mesa, but it is
totally unusable for anything serious (even OpenCL 1.1 and OpenCL 1.2).
Even clinfo would dump core after displaying lots of infos on the GPU.

Then there is AMD-APP, which is supposed to support OpenCL 1.2, but
that is part of closed driver amdgpu-pro, which runs only on Linux.

I'm dual-booting FreeBSD and Manjaro-Linux just to be able to do OpenCL
stuff on Linux. But even there, the opencl-amd AUR package which
extracts the OpenCL bits from the amdgpu-pro driver and puts them into
the (much better and newer) amdgpu driver causes some packages like,
say, xmr-stak-amd to generate invalid results on the GPU... which is,
according to xmr-stak-amd developer due to the opencl support in
amdgpu-pro 18.x driver to be broken, and that one has to downgrade
to amdgpu-pro 17.x opencl.

It is not easy to use OpenCL on AMD right now. They are developing
the ROCm platform[1], which looks promising, but they are not there yet.

[1] https://rocm.github.io/

> Best regards,
> Tomek

Regards,
cpghost.

[CeDeROM]

On Sun, Sep 2, 2018 at 12:45 PM Steve O'Hara-Smith <st...@sohara.org> wrote:
> > What is the current AMD/ATI support for Open-Source? Do they provide
> > full GPU specification as opposed to nVidia?
>
> AMD/ATI opened up their interfaces and some core source code about a
> decade ago they still produce a closed source driver of their own but they
> support the open source Linux video driver apparently enthusiastically
> (according to one report it is now faster than the closed source one).
>
> Both Intel and AMD/ATI provide open source OpenCL stacks
>
> It really is nVidia that is the odd one out - but they do hold the
> high end of the hardware, the cards gamers and cryptocurrency miners lust
> after are all nVidia.

Hmm, then I could consider ATI/AMD Radeon RX570 or 2x cheaper RX560..
anyone had any experience with those beasts and OpenCL on FreeBSD (and
outside)? :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

[CeDeROM]

On Sun, Sep 2, 2018 at 11:55 PM CeDeROM <ced...@tlen.pl> wrote:
> On Sun, Sep 2, 2018 at 12:45 PM Steve O'Hara-Smith <st...@sohara.org> wrote:
> > > What is the current AMD/ATI support for Open-Source? Do they provide
> > > full GPU specification as opposed to nVidia?
> >
> > AMD/ATI opened up their interfaces and some core source code about a
> > decade ago they still produce a closed source driver of their own but they
> > support the open source Linux video driver apparently enthusiastically
> > (according to one report it is now faster than the closed source one).
> >
> > Both Intel and AMD/ATI provide open source OpenCL stacks
> >
> > It really is nVidia that is the odd one out - but they do hold the
> > high end of the hardware, the cards gamers and cryptocurrency miners lust
> > after are all nVidia.
>
> Hmm, then I could consider ATI/AMD Radeon RX570 or 2x cheaper RX560..
> anyone had any experience with those beasts and OpenCL on FreeBSD (and
> outside)? :-)

Okay, so I have tested on ATI/AMD Radeon XT7870, and clinfo shows some
stuff.. but also gets some error that propagates to upper layer
applications..

I have noticed that when I also install Intel driver for OpenCL there
are errors because there is no underlying hardware. CPU based OpenCL
driver is nice to test some stuff.

It still needs some work but I can see that ATI/AMD really left nVidia
far behind in the Open-Source world.

I have just ordered ATI/AMD RADEON RX 580 :-)

AMD ROX! =)
NVIDIA SUX! =)

[CeDeROM]

Just to conclude:

NVIDIA SUX - just as most of you stated no support from nVidia to
Open-Source and more interesting OpenCL applications of their GPU -
after almost 15 years of being loyal customer (purchased 5+ cards and
recommended to others) I say GOODBYE NVIDIA WILL NOT RECOMMEND YOU TO
ANYONE ANYMORE!

ATI/AMD RADEON ROX - I have just bought RADEON RX 580 and OpenCL seems
available here - HELLO AMD RADEON - you have just re-gained old
customer I missed your smooth edges and better colors :-)

# clinfo
Number of platforms 2
Platform Name Clover
Platform Vendor Mesa
Platform Version OpenCL 1.1 Mesa 18.1.5
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix MESA

Platform Name Portable Computing Language
Platform Vendor The pocl project
Platform Version OpenCL 2.0 pocl
0.14, LLVM 4.0.1
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix POCL

Platform Name Clover
Number of devices 1
Device Name Radeon RX 580 Series
(POLARIS10, DRM 3.8.0, 11.2-RELEASE-p2, LLVM 6.0.1)
Device Vendor AMD
Device Vendor ID 0x1002
Device Version OpenCL 1.1 Mesa 18.1.5
Driver Version 18.1.5
Device OpenCL C Version OpenCL C 1.1
Device Type GPU
Device Profile FULL_PROFILE
Max compute units 36
Max clock frequency 1366MHz
Max work item dimensions 3
Max work item sizes 256x256x256
Max work group size 256
Preferred work group size multiple 64
Preferred / native vector sizes
char 16 / 16
short 8 / 8
int 4 / 4
long 2 / 2
half 8 / 8
(cl_khr_fp16)
float 4 / 4
double 2 / 2
(cl_khr_fp64)
Half-precision Floating-point support (cl_khr_fp16)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Address bits 64, Little-Endian
Global memory size 8552468480 (7.965GiB)
Error Correction support No
Max memory allocation 7697221632 (7.169GiB)
Unified memory for Host and Device No
Minimum alignment for any data type 128 bytes
Alignment of base address 32768 bits (4096 bytes)
Global Memory cache type None
Image support No
Local memory type Local
Local memory size 32768 (32KiB)
Max constant buffer size 2147483647 (2GiB)
Max number of constant args 16
Max size of kernel argument 1024
Queue properties
Out-of-order execution No
Profiling Yes
Profiling timer resolution 0ns
Execution capabilities
Run OpenCL kernels Yes
Run native kernels No
Device Available Yes
Compiler Available Yes
Device Extensions
cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics
cl_khr_int64_extended_atomics cl_khr_fp64 cl_khr_fp16

Platform Name Portable Computing Language
Number of devices 1
Device Name AMD Phenom(tm) II X6
1090T Processor
Device Vendor pocl
Device Vendor ID 0x1002
Device Version OpenCL 2.0 pocl
HSTR: pthread-x86_64-portbld-freebsd11.1-westmere
Driver Version 0.14
Device OpenCL C Version OpenCL C 2.0
Device Type CPU, Default
Device Profile FULL_PROFILE
Max compute units 6
Max clock frequency 3200MHz
Device Partition (core)
Max number of sub-devices 6
Supported partition types equally, by counts
Max work item dimensions 3
Max work item sizes 4096x4096x4096
Max work group size 4096
Preferred work group size multiple 8
Preferred / native vector sizes
char 16 / 16
short 8 / 8
int 4 / 4
long 2 / 2
half 8 / 8 (n/a)
float 4 / 4
double 2 / 2
(cl_khr_fp64)
Half-precision Floating-point support (n/a)
Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Double-precision Floating-point support (cl_khr_fp64)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Address bits 64, Little-Endian
Global memory size 19033886720 (17.73GiB)
Error Correction support No
Max memory allocation 19033886720 (17.73GiB)
Unified memory for Host and Device Yes
Shared Virtual Memory (SVM) capabilities (core)
Coarse-grained buffer sharing Yes
Fine-grained buffer sharing Yes
Fine-grained system sharing No
Atomics Yes
Minimum alignment for any data type 128 bytes
Alignment of base address 1024 bits (128 bytes)
Preferred alignment for atomics
SVM 0 bytes
Global 0 bytes
Local 0 bytes
Max size for global variable 0
Preferred total size of global vars 0
Global Memory cache type Read/Write
Global Memory cache size 65536
Global Memory cache line 64 bytes
Image support Yes
Max number of samplers per kernel 16
Max size for 1D images from buffer 1189617920 pixels
Max 1D or 2D image array size 2048 images
Max 2D image size 32768x32768 pixels
Max 3D image size 2048x2048x2048 pixels
Max number of read image args 128
Max number of write image args 128
Max number of read/write image args 128
Max number of pipe args 16
Max active pipe reservations 1
Max pipe packet size 1024
Local memory type Global
Local memory size 19033886720 (17.73GiB)
Max constant buffer size 19033886720 (17.73GiB)
Max number of constant args 8
Max size of kernel argument 1024
Queue properties (on host)
Out-of-order execution No
Profiling Yes
Queue properties (on device)
Out-of-order execution Yes
Profiling Yes
Preferred size 16384 (16KiB)
Max size 262144 (256KiB)
Max queues on device 1
Max events on device 1024
Prefer user sync for interop Yes
Profiling timer resolution 1ns
Execution capabilities
Run OpenCL kernels Yes
Run native kernels Yes
SPIR versions 1.2
printf() buffer size 1048576 (1024KiB)
Built-in kernels
Device Available Yes
Compiler Available Yes
Linker Available Yes
Device Extensions
cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_spir cl_khr_int64
cl_khr_fp64 cl_khr_int64_base_atomics cl_khr_int64_extended_atomics

NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [MESA]
clCreateContext(NULL, ...) [default] Success [MESA]
clCreateContext(NULL, ...) [other] Success [POCL]
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found
in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) Success (1)
Platform Name Clover
Device Name Radeon RX 580 Series
(POLARIS10, DRM 3.8.0, 11.2-RELEASE-p2, LLVM 6.0.1)
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No
devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices
found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1)
Platform Name Clover
Device Name Radeon RX 580 Series
(POLARIS10, DRM 3.8.0, 11.2-RELEASE-p2, LLVM 6.0.1)

ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.2.12
ICD loader Profile OpenCL 2.2
NOTE: your OpenCL library declares to support OpenCL 2.2,
but it seems to support up to OpenCL 2.1 only.
Segmentation fault (core dumped) <--- ;-)

Except DRM and AMDGPU firmware it still needs some more tweaking, but
this is clearly a proof of hardware vendor support for Open-Source
Community :-)

"It's not Open-Source if not runs on FreeBSD"^TM :-)

Thank you folks! :-)
Tomek

[Mario Marietto]

the way to go here is that some developers looks inside the source code of qemu and kvm to understand how they works and then they copy the essential components to implement the pass thru of the nvidia graphic card into bhyve. So,we will pass thru the nvidia card inside a bhyve vm and we will install linux inside it with the cuda libraries. bingo.

[BeneschTech LLC]

https://www.nvidia.com/Download/driverResults.aspx/184165/en-us

It doesnt support CUDA, but at least its more hardware compliant,