OpenCL kernel build fails on Linux with Mesa drivers (RX 480) #50522

New Issue

Added subscriber: @Sergey

Sergey Sharybin commented

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

Sergey Sharybin self-assigned this 2017-01-25 11:56:02 +01:00

Sergey Sharybin commented

2017-02-09 14:25:47 +01:00

Thanks for the report, but we simply don't officially support MESA OpenCL implementation yet.

Nick Ashley commented

Added subscriber: @nashley

Nick Ashley commented

2017-02-09 14:33:27 +01:00

I am also experiencing a similar error with my R9 280X running opencl-mesa 13.0.4-1 and ocl-icd 2.2.10-1 on Arch Linux x86_64 4.9.8-1 (Blender version 2.78.a).

In #50522#413817, @Sergey wrote:
Thanks for the report, but we simply don't officially support MESA OpenCL implementation yet.

When, if ever, can we expect Blender's OpenCL builds to be compatible with mesa drivers?

With a little dedication, would an amateur OpenGL developer be able to help fix this?

I am also experiencing a similar error with my `R9 280X` running `opencl-mesa 13.0.4-1` and `ocl-icd 2.2.10-1` on `Arch Linux x86_64 4.9.8-1` (Blender version `2.78.a`). > In #50522#413817, @Sergey wrote: > Thanks for the report, but we simply don't officially support MESA OpenCL implementation yet. When, if ever, can we expect Blender's OpenCL builds to be compatible with mesa drivers? With a little dedication, would an amateur OpenGL developer be able to help fix this?

Ian Bruce commented

Added subscriber: @ian_bruce

Ian Bruce commented

Changed status from 'Archived' to: 'Open'

Ian Bruce reopened this issue

Ian Bruce commented

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848258

This same problem (actually, several problems) has been reported here; it's not distribution- or hardware-specific:

Fortunately, all these problems are now solvable.

The "double precision constant requires cl_khr_fp64" compiler warning has just been addressed here:

https://developer.blender.org/rB2d3c44389ab7

I'm not clear on the origin of the compiler warning "implicit declaration of function {lgamma,native_tan} is invalid in C99"; I haven't been able to find out where these openCL functions are supposed to be defined. (Does anybody know?) But it's only a warning, so it may not matter.

There are three actual compile errors of the form "invalid argument type 'X *' to unary expression". This seems to be a problem with using a pointer as a boolean value, under some version of the C language standard; it's usually OK, as far as I know. A patch for this is attached below:

blender-cycles-ptr.diff

The "unsupported call to function get_local_size" error is a Mesa/LLVM problem. A patch is available upstream; it is recommended that Linux distributions apply it locally:

https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24

Perhaps these changes can be made, and then openCL GPU rendering retested, to see if it then works.

2017-03-13 10:00:20 +01:00

This same problem (actually, several problems) has been reported here; it's not distribution- or hardware-specific: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848258 Fortunately, all these problems are now solvable. The **"double precision constant requires cl_khr_fp64"** compiler warning has just been addressed here: https://developer.blender.org/rB2d3c44389ab7 I'm not clear on the origin of the compiler warning **"implicit declaration of function {lgamma,native_tan} is invalid in C99"**; I haven't been able to find out where these openCL functions are supposed to be defined. (Does anybody know?) But it's only a warning, so it may not matter. There are three actual compile errors of the form **"invalid argument type 'X *' to unary expression"**. This seems to be a problem with using a pointer as a boolean value, under some version of the C language standard; it's usually OK, as far as I know. A patch for this is attached below: [blender-cycles-ptr.diff](https://archive.blender.org/developer/F508065/blender-cycles-ptr.diff) The **"unsupported call to function get_local_size"** error is a Mesa/LLVM problem. A patch is available upstream; it is recommended that Linux distributions apply it locally: https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24 Perhaps these changes can be made, and then openCL GPU rendering retested, to see if it then works. <ian_bruce@mail.ru>

Sergey Sharybin commented

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2017-03-13 10:00:20 +01:00

Sergey Sharybin commented

2017-03-13 10:00:20 +01:00

I've applied the patch at 8794a43 just because i prefer explicit NULL comparisons my self.

Keep in mind that this is a proper C syntax and there is no reason why OpenCL which is C99-based will forbid this. In fact, this code works just fine on AMD/Intel/NVidia drivers.

Since this is a valid syntax, there is a very high likelyhood of this issue happening again.

So preference is to get this fixed in MESA itself.

Please also note that for such a collaboration about unsupported platform we expect either ML/IRC or a patch tracker used. We do not accept bug reports about platforms we do not officially support.

I've applied the patch at 8794a43 just because i prefer explicit NULL comparisons my self. Keep in mind that this is a proper C syntax and there is no reason why OpenCL which is C99-based will forbid this. In fact, this code works just fine on AMD/Intel/NVidia drivers. Since this is a valid syntax, there is a very high likelyhood of this issue happening again. So preference is to get this fixed in MESA itself. Please also note that for such a collaboration about unsupported platform we expect either ML/IRC or a patch tracker used. We do not accept bug reports about platforms we do not officially support.

Ian Bruce commented

2017-03-13 11:03:20 +01:00

It turns out that the *"invalid argument type 'X ' to unary expression" compile errors are the result of a known bug in LLVM. It is said to be fixed in LLVM-v5; see here:

https://bugs.llvm.org/show_bug.cgi?id=30217

https://reviews.llvm.org/D29038

https://reviews.llvm.org/rL294313

a trivial test case illustrating the bug:

$ cat ptr-expr2.c
int ptr_expr(int *p)
{
    if (!p)
        return(0);
    else
        return(1);
}
$ 
$ clang-3.9 -x cl -emit-llvm -S ptr-expr2.c
ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression
    if (!p)
        ^~
1 error generated.
$ 
$ clang-4.0 -x cl -emit-llvm -S ptr-expr2.c
ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression
    if (!p)
        ^~
1 error generated.
$ 
$ clang-5.0 -x cl -emit-llvm -S ptr-expr2.c
$ # compilation succeeds

Since LLVM is the cause of the problem, patching completely correct Blender code, as I suggested above, is probably not an appropriate solution.

Instead, distributions should either require LLVM-v5 for openCL, or backport the bugfix into their current LLVM version -- it appears to be a single-line change (see link above).

Alternatively, the LLVM maintainers could be made aware that pre-version-5 LLVM is currently unusable for openCL, and asked to backport the fix into an earlier version, themselves.

2017-03-13 15:02:31 +01:00

It turns out that the **"invalid argument type 'X *' to unary expression"** compile errors are the result of a known bug in LLVM. It is said to be fixed in LLVM-v5; see here: https://bugs.llvm.org/show_bug.cgi?id=30217 https://reviews.llvm.org/D29038 https://reviews.llvm.org/rL294313 a trivial test case illustrating the bug: ``` $ cat ptr-expr2.c int ptr_expr(int *p) { if (!p) return(0); else return(1); } $ $ clang-3.9 -x cl -emit-llvm -S ptr-expr2.c ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression if (!p) ^~ 1 error generated. $ $ clang-4.0 -x cl -emit-llvm -S ptr-expr2.c ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression if (!p) ^~ 1 error generated. $ $ clang-5.0 -x cl -emit-llvm -S ptr-expr2.c $ # compilation succeeds ``` Since LLVM is the cause of the problem, patching completely correct Blender code, as I suggested above, is probably not an appropriate solution. Instead, distributions should either require LLVM-v5 for openCL, or backport the bugfix into their current LLVM version -- it appears to be a single-line change (see link above). Alternatively, the LLVM maintainers could be made aware that pre-version-5 LLVM is currently unusable for openCL, and asked to backport the fix into an earlier version, themselves. <ian_bruce@mail.ru>

Ian Bruce commented

The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports. Patches are available upstream for both problems, as mentioned above.

unsupported call to function get_local_size

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857591

*invalid argument type 'X ' to unary expression

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857623

Other distributions may wish to take note of the results, and resolve these issues in a similar way.

2017-03-18 12:56:26 +01:00

The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports. Patches are available upstream for both problems, as mentioned above. **unsupported call to function get_local_size** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857591 **invalid argument type 'X *' to unary expression** https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857623 Other distributions may wish to take note of the results, and resolve these issues in a similar way. <ian_bruce@mail.ru>

Ian Bruce commented

It turns out that these compiler warnings --

implicit declaration of function {lgamma,native_tan} is invalid in C99

occur because the version of libclc (Mesa openCL) being used is not recent enough to have implemented those functions; one has only been available for a few weeks. These are the relevant development commits:

07fa4ae82d

a2593ed8ad

Debian bug report for this issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857710

This bug, and the two above, are aggregated here, so these problems can be resolved as quickly as possible:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857718

All three problems are fixable NOW, as I have described. Other distributions should apply these patches and updates in their own archives.

It appears that if this were done, GPU rendering with openCL might very well start working.
People who are interested in this outcome should apply pressure in appropriate places; it's no longer a Blender problem.

2017-03-18 13:32:25 +01:00

It turns out that these compiler warnings -- **implicit declaration of function {lgamma,native_tan} is invalid in C99** occur because the version of libclc (Mesa openCL) being used is not recent enough to have implemented those functions; one has only been available for a few weeks. These are the relevant development commits: https://github.com/llvm-mirror/libclc/commit/07fa4ae82da5fa75af174f30c498ff160bbf8644 https://github.com/llvm-mirror/libclc/commit/a2593ed8adbf7386f88dfc828cfc32f788ec3983 Debian bug report for this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857710 This bug, and the two above, are aggregated here, so these problems can be resolved as quickly as possible: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857718 All three problems are fixable NOW, as I have described. Other distributions should apply these patches and updates in their own archives. It appears that if this were done, GPU rendering with openCL might very well start working. People who are interested in this outcome should apply pressure in appropriate places; it's no longer a Blender problem. <ian_bruce@mail.ru>

Sergey Sharybin commented

@ian_bruce, i'm not sure what we can do with that knowledge. We are not drivers developers and are not involved into any distro development process. Guess this info better be directed to distro maintainers to ensure they ship proper drivers for OpenCL support (Blender is not the only program on planet which will benefit from that ;)

Ian Bruce commented

2017-03-19 08:54:16 +01:00

Yes, that's exactly what I said --

i'm not sure what we can do with that knowledge.

"Since LLVM is the cause of the problem, patching completely correct Blender code, as I suggested above, is probably not an appropriate solution."

We are not drivers developers and are not involved into any distro development process.

"The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports."

Guess this info better be directed to distro maintainers to ensure they ship proper drivers for OpenCL support

"This bug, and the two above, are aggregated here, so these problems can be resolved as quickly as possible:"

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857718

"Other distributions should apply these patches and updates in their own archives. It appears that if this were done, GPU rendering with openCL might very well start working. People who are interested in this outcome should apply pressure in appropriate places; it's no longer a Blender problem."

Blender is not the only program on planet which will benefit from that

I found this discussion when I was searching for information on the same problem; it seems that there are more than fifteen people subscribed to it. Presumably other people will find it as well:

https://www.google.com/search?q=blender+mesa+opencl (second result)

I have now told anybody who cares, that "it's no longer a Blender problem", and that they should "apply pressure in appropriate places", "distributions should apply these patches and updates in their own archives." Along with exactly which patches and updates need to be applied to get openCL working for this or any other application.

It seems to me that this is all useful information for anybody who cares about the issue, and since the question was asked here, this is where I've answered it. Nobody need ask it again; I've told them exactly what their distribution needs to do to fix the problem, and filed appropriate bug reports for Debian, myself. Now other people can file appropriate bug reports with their distributions, and GPU rendering on AMD hardware can finally be made to work.