Create option to use OpenCL instead of CUDA

[bkeys-RFA]

Is there any plan to enable this as an option? It would be nice if PhysX followed the free software guidelines that way it could be packaged and included into the repositories of most mainstream distros, making the library more accessible to developers and people running non-nvidia hardware.

[Degerz]

Not an Nvidia employee so here's my opinion ...

There's no purpose for an OpenCL backend since games or game engines will never be caught using OpenCL to begin with. For other professional software, there are better options than using PhysX ...

What software would even use both OpenCL and PhysX together ?

[Ruedii]

The Bullet Physics engine and Havok Physics engine both use OpenCL already.

However, many are moving to Vulkan Compute extensions because it permits better scheduling integration with GPU.

I would recommend supporting Vulkan Compute instead. Currently android supports Vulkan compute, while it doesn't support OpenCL.

[Degerz]

OK, it looks like I have some myth busting to do ...

First, the Havok Physics engine never had an OpenCL backend to begin with ...

Second, Android platforms do support OpenCL if anyone ever checks Khronos conformant OpenCL products ...

I guess this is an example of why people should refrain from posting if they aren't programmers or don't have much technical knowledge ...

[Ruedii]

OK, it looks like I have some myth busting to do ...

First, the Havok Physics engine never had an OpenCL backend to begin with ...

Second, Android platforms do support OpenCL if anyone ever checks Khronos conformant OpenCL products ...

I guess this is an example of why people should refrain from posting if they aren't programmers or don't have much technical knowledge ...

First, Please read people's messages.

Yes, some do support OpenCL, but the vast majority do not support GPU OpenCL. A fair number support CPU OpenCL out of box to get much better parallel compute management.

Android supports Vulkan Compute on newer versions, and it is a much better option.

Similarly Havok did exeriment with OpenCL, but chose to go with platform specific compute solutions tied into the graphics stack. (OpenGL ShaderCompute, Vulkan ShaderCompute and Direct3D ShaderCompute). As a note, the former two are very similar to OpenCL, although not entirely identical (largely having differences in memory management.)

Second, please don't insult people, it is rude and unprofessional.

[Degerz]

First, Please read people's messages.

How about you educate yourself first ? Because once again nearly nothing you posted were facts ...

Yes, some do support OpenCL, but the vast majority do not support GPU OpenCL. A fair number support CPU OpenCL out of box to get much better parallel compute management.

FYI, ARM had a conformant OpenCL device driver implementation for their GPUs dating back to 2012 when they first debuted their Midgard architecture ?! It's the same thing with Qualcomm's Adreno 3XX ...

Similarly Havok did exeriment with OpenCL, but chose to go with platform specific compute solutions tied into the graphics stack. (OpenGL ShaderCompute, Vulkan ShaderCompute and Direct3D ShaderCompute). As a note, the former two are very similar to OpenCL, although not entirely identical (largely having differences in memory management.)

So much misinformation here I don't even know where to start, wow. The Havok physics engine is STILL CPU based to this very day and PC gfx APIs like D3D or Vulkan do NOT look anything like OpenCL so I have no idea what you're even talking about there. D3D/GL/VK compute shader execution model is completely different to OpenCL's kernel execution model and they do not even have anywhere near the same capabilities as OpenCL C kernels do if you take look at the clspv project documentation on the restrictions of compiling OpenCL C kernels to SPIR-V compute shaders. clspv fails pretty hard at compiling more complex kernels so they only work on the simplest OpenCL subset.

Second, please don't insult people, it is rude and unprofessional.

I wasn't insulting you, I was only correcting your extreme ignorance since you have no idea on any of these subjects you're talking about so please don't bother showing yourself up again along these extremely technical boards in order to avoid the self-embarrassment ?

[Ruedii]

First, Please read people's messages.

How about you educate yourself first ? Because once again nearly nothing you posted were facts ...

YOU POSTED THE FACTS REGARDING THINGS DIFFERENT THAN WHAT I SAID!!

I said SPIR-CL, and you presumed old, depricated, OpenCL Kernel mode.

You then presumed I was referring to the idiotic transassembler you tried, that clearly can't even split a pipeline. Did you ever think to look for a different solution, or are you too full of yourself? YOU are clearly the one with no technical expertise, or at LEAST no ability to RESEARCH A TERM YOU DON'T RECOGNIZE.

I was referring to the ability to write common code, as I mentioned in the FIRST POST I MADE. However, concepts like compiler directives must be beyond your stubborn little brain. You seem to think I just meant to feed it in a coversion stack or something because that is what you would do. You are an egotistical fool!

Yes, some do support OpenCL, but the vast majority do not support GPU OpenCL. A fair number support CPU OpenCL out of box to get much better parallel compute management.

FYI, ARM had a conformant OpenCL device driver implementation for their GPUs dating back to 2012 when they first debuted their Midgard architecture ?! It's the same thing with Qualcomm's Adreno 3XX ...

ARM is compliant, but the Operating systems on the devices are not. They do not have the necessary libraries installed. If you check OpenCL capability on ACTUAL REAL WORLD DEVICES, it is far and few between. The reason for this is OpenCL is battery intensive. However, if you check Vulkan support, you will find it.

OpenCL Support for the hardware is useless if the driver isn't shipped on the device. We aren't designing an OS here, we are designing a APPLICATION LAYER LIBRARY.

Similarly Havok did exeriment with OpenCL, but chose to go with platform specific compute solutions tied into the graphics stack. (OpenGL ShaderCompute, Vulkan ShaderCompute and Direct3D ShaderCompute). As a note, the former two are very similar to OpenCL, although not entirely identical (largely having differences in memory management.)

So much misinformation here I don't even know where to start, wow. The Havok physics engine is STILL CPU based to this very day and PC gfx APIs like D3D or Vulkan do NOT look anything like OpenCL so I have no idea what you're even talking about there. D3D/GL/VK compute shader execution model is completely different to OpenCL's kernel execution model and they do not even have anywhere near the same capabilities as OpenCL C kernels do if you take look at the clspv project documentation on the restrictions of compiling OpenCL C kernels to SPIR-V compute shaders. clspv fails pretty hard at compiling more complex kernels so they only work on the simplest OpenCL subset.

I NEVER said ALL OpenCL code will work on OpenGL Compute and SPIR-V. I SAID you can easily target all three platforms. Anyone with the slightest bit of technical expertise would presume I meant through the use of compiler directive, not simply feeding it into another compiler.

Additionally, you could convert it IF you broke the code into pipeline stages, but that would require a transcompiler, but you looked up a transassembler, because you are a stubborn egotistical fool who thinks he's always right.

If you actually READ my post, you would see I was referring to the pipeline-based SPIR-CL execution model (NOT SPIR-V) that was introduced in newer OpenCL versions. This newer execution model is NIV Pipeline based, unlike the OLD DEPRICATED kernel based configuration.

Also, if your compiler fails, it doesn't mean it doesn't work. It means your compiler is insufficient for the subset you want to use.

Also, while the primary physics for Havok do not use GPU, because CPU is sufficient, effects physics DO use GPU acceleration. This includes cloth effects and other effects that extrapolate data FROM the CPU equations.

Second, please don't insult people, it is rude and unprofessional. I wasn't insulting you, I was only correcting your extreme ignorance since you have no idea on any of these subjects you're talking about so please don't bother showing yourself up again along these extremely technical boards in order to avoid the self-embarrassment ?

Why are you presuming I have no technical ability!!!!!!! You simply have no communication ability and CANNOT READ THE FULL MESSAGE!!!! THAT IS INSULTING!!! QUIT READING HALF MY THREAD THEN INSULTING ME TO STROKE YOUR EGO!

NOW STOP DERAILING THIS THREAD, IT IS UNPROFESSIONAL. YOU ARE INSULTING MY INTELLIGENCE WITH YOUR LITTLE EGO TRIP AND YOU NEED TO STOP NOW!!! YOU ARE MAKING ASSUMPTIONS INSTEAD OF ASKING FOR CLARIFICATIONS.

[Degerz]

YOU POSTED THE FACTS REGARDING THINGS DIFFERENT THAN WHAT I SAID!!

I said SPIR-CL, and you presumed old, depricated, OpenCL Kernel mode.

You then presumed I was referring to the idiotic transassembler you tried, that clearly can't even split a pipeline. Did you ever think to look for a different solution, or are you too full of yourself? YOU are clearly the one with no technical expertise, or at LEAST no ability to RESEARCH A TERM YOU DON'T RECOGNIZE.

I was referring to the ability to write common code, as I mentioned in the FIRST POST I MADE. However, concepts like compiler directives must be beyond your stubborn little brain. You seem to think I just meant to feed it in a coversion stack or something because that is what you would do. You are an egotistical fool!

It's funny to see you getting absolutely defensive instead of strictly being technical and I sense some fear that you are not actually knowledgeable as you let on to be since you seem to keep beating around the bush ...

ARM is compliant, but the Operating systems on the devices are not. They do not have the necessary libraries installed. If you check OpenCL capability on ACTUAL REAL WORLD DEVICES, it is far and few between. The reason for this is OpenCL is battery intensive. However, if you check Vulkan support, you will find it.

OpenCL Support for the hardware is useless if the driver isn't shipped on the device. We aren't designing an OS here, we are designing a APPLICATION LAYER LIBRARY.

Once again you're wrong. Vulkan support is more rare than OpenCL support on Android. OpenCL can be had on Android devices as far back with Android version 4.x while Vulkan support is only available on Android version 6+ ...

I NEVER said ALL OpenCL code will work on OpenGL Compute and SPIR-V. I SAID you can easily target all three platforms. Anyone with the slightest bit of technical expertise would presume I meant through the use of compiler directive, not simply feeding it into another compiler.

It's pretty clear from here that you know absolutely nothing about GPU compute so let me correct you once again ...

MOST OpenCL code will not work on compute shaders, period! Compiler directives are useless garbage that doesn't help much and it's not trivial at all to port OpenCL C kernels to compute shaders. One of the big limitations with compute shaders is that they don't have or have very limited support for pointers compared to OpenCL which is a major functionality gap ...

Additionally, you could convert it IF you broke the code into pipeline stages, but that would require a transcompiler, but you looked up a transassembler, because you are a stubborn egotistical fool who thinks he's always right.

Transcompiler ? Transassembler ? Big words coming from a stranger with likely no programming background ...

I bet you don't even know the other reason why a 'transcompiler' wouldn't even be feasible in the case of OpenCL/Vulkan so why don't you figure that out for some exercise ?

If you actually READ my post, you would see I was referring to the pipeline-based SPIR-CL execution model (NOT SPIR-V) that was introduced in newer OpenCL versions. This newer execution model is NIV Pipeline based, unlike the OLD DEPRICATED kernel based configuration.

Also, if your compiler fails, it doesn't mean it doesn't work. It means your compiler is insufficient for the subset you want to use.

Oh please, clspv is the most optimistic case to get OpenCL C kernels running on SPIR-V compute shaders ...

Also, while the primary physics for Havok do not use GPU, because CPU is sufficient, effects physics DO use GPU acceleration. This includes cloth effects and other effects that extrapolate data FROM the CPU equations.

I'm not sure where you get your information but Havok does NOT do GPU accelerated cloth physics. Just about every developer I know has a customized GPU solver for doing cloth physics based on computer shaders ...

Why are you presuming I have no technical ability!!!!!!! You simply have no communication ability and CANNOT READ THE FULL MESSAGE!!!! THAT IS INSULTING!!! QUIT READING HALF MY THREAD THEN INSULTING ME TO STROKE YOUR EGO!

NOW STOP DERAILING THIS THREAD, IT IS UNPROFESSIONAL. YOU ARE INSULTING MY INTELLIGENCE WITH YOUR LITTLE EGO TRIP AND YOU NEED TO STOP NOW!!! YOU ARE MAKING ASSUMPTIONS INSTEAD OF ASKING FOR CLARIFICATIONS.

It's not like I need any communication ability when I actually know what I'm talking about unlike you who have thus far demonstrated no technical knowledge ...

It's clear that you're absolutely not suited to take discussions around these boards so it's only appropriate that you never participate in any other future discussions involving these subject matters ...

[vault-thirteen]

The CUDA-Corp. is making money and selling graphic cards with 128-bit memory bus instead of 192-bit and 256-bit bus as in previous series. They can not afford sharing open source technologies because they will start losing money if less people buy their magic CUDA-only devices. I am happy that Intel has enetered this market and is providing good GPUs which are capable of using OpenCL. And Intel's drivers are getting better and better every next month.