How to get 64-bit addressing, full RAM access using OpenCL with 2019 MacBook Pro 16" intel/amd - macos

I have a 2019 MacBook Pro 16". It has an Intel Core i9, 8-core processor and an AMD Radeon Pro 5500M with 8 GB GPU RAM.
I have the laptop dual booting Mac OS 12.4 and Windows 11.
Running clinfo under Windows tells me essentially that the OpenCL support is version 2.0, and that the addressing is 64-bits, and the max allocatable memory is between 7-8 GB.
Running clinfo under Mac OS tells me that OpenCL support is version 1.2, that addressing is 32-bits little endian, and the max allocatable memory is about 2 GB.
I am guessing this means that any OpenCL code I run is then restricted to using 2GB because of the 32-bit addressing (I thought that limit was 4GB), but I am wondering a) is this true and b) if it is true, is there any way to enable OpenCL under Mac to use the full amount of GPU memory?

OpenCL support on macOS is not great and has not been updated/improved for almost a decade. It always maxes out at version 1.2 regardless of hardware.
I'm not sure how clinfo determines "max allocatable memory," but if this refers to CL_DEVICE_MAX_MEM_ALLOC_SIZE, this is not necessarily a hard limit and can be overly conservative at times. 32-bit addressing may introduce a hard limit though. I'd also experiment with allocating your memory as multiple buffers rather than one giant one.
For serious GPU programming on macOS, it's hard to recommend OpenCL these days - tooling and feature support on Apple's own Metal API is much better, but of course not source compatible with OpenCL and only available on Apple's own platforms. (OpenCL is now also explicitly deprecated on macOS.)

Related

Unreal engine - complaints for needing 8 GB of memory even though I have 8GB memory

I have a Mac OS X with 8 GB 1600 MHz DDR3 RAM and when I start unreal engine it complaints about Low RAM and asks that for best performance I should have at least 8 GB of RAM.
I'm not sure why is this is case, is it possible that its getting a lower share of RAM or something similar?
The Unreal Editor version is 4.7.5
Edit: The processor is 2.3 GHz Intel Core i7, and is 64 bit.
Edit: The graphic processor is Intel Iris Pro 1024 MB.
Why would UE4 not be able to access all of your RAM? I do not consider that case very likely.
Also, I would not worry about the RAM usage of UE4 too much. I do a lot of work with the engine and it rarely uses more than 3GB of RAM. Just make sure that your system as a whole has enough RAM for the running processes to prevent swapping.
Anyway, the bottleneck in your system is probably the graphics processor, so if your engine runs too slowly you should reduce the performance setting inside the engine.

Different audio quality between Mac Pro and MacBook Pro with the same xcode Release

I wrote a program with xcode (using portaudio) on a MacBook Pro (Intel Core 2 Duo 2.66 GHz). The Release works without problem (clear audio streaming) and the CPU Usage Level is almost 90%.
The problem arises when i run the Release on a Mac Pro (Quad Core Intel Xeon 2.8 GHz). The audio stream, when there is a large amount of computation, isn't clear (there are little clicks) despite the use of the CPU is four times lower than the one of MacBook Pro.
I can not understand why this happens.
25% CPU usage in a 4 core system means one core is 100% loaded. Also, I assume the Xeons are Pentium4 Xeons, which have way worse CPU cores than the Core2Duo, even though the clock frequency is a bit higher...

Install AMD OpenCL CPU driver with an Nvidia graphic card

I have seen this question many times but never found an answer for Windows.
I recently ported my CUDA code to OpenCL.
When testing with an ATI card, the Catalyst drivers contain a CPU OpenCL driver, hence I can run the OpenCL code on the CPU.
When testing with an NVIDIA card, there is no driver for the CPU.
Question is: how can I install (and deploy) a CPU driver when running with an Nvidia card?
Thanks a lot
To use OpenCL on CPU you don't need any driver, you only need OpenCL runtime that supports CPU, which (in case of AMD/ATI) is part of APP SDK. It could be installed no matter what GPU you have. Your end-users would also have to install the APP SDK: currently, there is no way to install OpenCL runtime only.
If you have Intel CPU, you better try Intel OpenCL SDK, which has separate installer. However, AMD APP SDK works on Intel CPUs quite well, but note vice versa.

if a 32-bit OS running on dual core 64-bit CPU, are both core performance's are lower?

if a 32-bit OS running on dual core 64-bit CPU, are both core performance's are lower?
what is exactly happening inside CPU?
Are the 2 cores still working together, and slower than if equipped with 64-bit OS?
I am using a Win 7 32-bit Professional on Intel P6200.
Thanks
The major advantage of 64-bit CPUs is their ability to address more memory. It generally won't affect speed. An exception might be where a given program can run faster with more RAM, and you actually have that much RAM (more than 4GB on Windows). (And, of course, the program must be a 64 bit application.)
The processors are working together in exactly the same way. They just have smaller address spaces with the 32 bit OS.
From user perspective a 64-bit operating system mostly just allows you to run 64-bit applications. And why would you do that?
If your application has a dedicated 64-bit version, and it is heavy on numerical calculations, which were optimized to use capabilities of x64 platform (mostly more general-purpose registers), or needs a lot of RAM (more than 2GB) at once, then there are chances it will work faster.
Otherwise, most probably it will work at the same speed as 32-bit version.
It makes very little difference but my experience is that a 64 bit OS runs some 32 bit apps very slightly better than a 32 bit OS. But it's marginal at best.

glGetError hangs for several seconds

I am developing an OpenGL application and I am seeing some strange things happen. The machine I am testing with is equipped with an NVidia Quadro FX 4600 and it is running RHEL WS 4.3 x86_64 (kernel 2.6.9-34.ELsmp).
I've stepped through the application with a debugger and I've noticed that it is hanging on OpenGL calls that are receiving information from the OpenGL API: i.e. - glGetError, glIsEnabled, etc. Each time it hangs up, the system is unresponsive for 3-4 seconds.
Another thing that is interesting is that if this same code is run on RHEL 4.5 (Kernel 2.6.9-67.ELsmp), it runs completely fine. The same code also runs perfectly on Windows XP. All machines are using the exact same hardware:
PNY nVidia Quadro FX4600 768mb PCI Express
Dual Intel Xeon DP Quad Core E5345 2.33hz
4096 MB 667 MHz Fully Buffered DDR2
Super Micro X7DAL-E Intel 5000X Chipset Dual Xeon Motherboard
Enermax Liberty 620 watt Power Supply
I have upgraded to the latest 64bit drivers: Version 177.82, Release Date: Nov 12, 2008 and the result is the exact same.
Does anyone have any idea what could be causing the system to hang on these OpenGL calls?
It appears that this is an issue with less-than-perfect NVidia drivers for Linux. Upgrading to a newer kernel appears to help. If I am forced to use this dated kernel, there are some things that I've tried that seem to help.
Defining the __GL_YIELD environment variable to "NOTHING" prior to starting X seems to increase stability with this older kernel.
http://us.download.nvidia.com/XFree86/Linux-x86_64/177.82/README/chapter-11.html
I've also tried disabling Triple Buffering and Flipping.
I've also found that these forums are very helpful for Linux/NVidia problems. Just do a search for "linux crash"
You may be able to dig deeper by using a system profiler like Sysprof or OProfile. Do other OpenGL applications using these calls exhibit similar behavior?

Resources