Anybody run the new app through the benchmarks yet with a comparison run against the default r3711 SSE41 cpu app?

After spending DAYS trying to get the AKv8 OpenCL App to compile in the newer Linux systems it has come to my attention a large number of Optimizations were left out of the CPU Apps. It May be possible to build a New CPU App with better speed using those said Optimizations. Right now I'm trying to find the System calls named by Eric & RueiKe that should be left out of the OpenCL App. Not having much luck. Anyone know just WHERE in the code "funsafe-math-optimizations" & "unsafe-fp-opt" are lurking? The New OpenCL App is a little faster than r3584, I suspect a Newer CPU App can be faster than r3711 as well.

I have verified that ROCm will have the same problem giving invalid results that was found with Navi on the latest Windows/Linux drivers. They all use the latest LC OpenCL compiler. I had tested ROCm on my Vega20 and confirmed the standard version gives invalid results. I have replaced a lib file with one that would not allow unsafe-math, and that system is giving valid results now. This lib file has other issues and can not be released, so we need to make the same app modification that was made for Windows. Perhaps the magnitude of the problem for Linux is small now, though if we looked hard enough, we could probably find some, but I would expect that new GPUs/drivers in Linux will cause the problem to increase in magnitude over time.

I would expect the unsafe options are related to the creation of the code that runs on the GPU and not the compile options for creating the CPU code. I am not so familiar with OpenCL programming, but I did check the binary with a viewer and did not see the same clear flags that Eric saw in the Windows app.

It seems to me that anybody hoping to create working GPU applications has to have a clear understanding of the various steps and processes that the application goes through; where they take place; and how they are controlled. My first attempt at a list goes something like this:

* x86 source code for the control component that runs on the CPU
* x86 compiler directives that manage the build process for the CPU app
* Build of x86 component - takes place on the developer's computer
* GPU source code (CUDA or OpenCL) for the GPU part of the application
* GPU compiler directives
* Build of GPU component - takes place on the end user's computer, using the source code and compiler directives provided by the developer, but actually done by the compiler shipped with the GPU drivers

It sounds as if the older generation of OpenCL compilers could be directed to use unsafe-math, but didn't do so by default: hence the compiler directive which Eric could find in the compiled x86 binary, for onward transmission to the OpenCL compiler. Sometimes x86 executables are compressed after compilation to save disk space and speed loading: if that was done, the human-readable strings could no longer be found in the compressed binary, but would still be there at runtime after decompression.

Maybe this new OpenCL compiler has changed the default - to use unsafe-math unless directed otherwise? In that case, the need would be to ADD a compiler directive "don't use unsafe-math" (in whatever syntax is applicable), rather than to REMOVE the existing "use unsafe-math"?