I’m thinking of #compiling #darktable from source so that it’s better optimized for my processor.
Anybody experience with its potential? #question #followerpower

I’m generally ok with how fast the flatpak runs on my i7-1255 laptop. However, with such an iterative workflow, I feel that one has much to gain with slight improvements via #opencl and AVX.

I'm liking the class this year. Students are attentive and participating, and the discussion is always productive.

We were discussing the rounding up of the launch grid in #OpenCL to avoid the catastrophic performance drops that come from the inability to divide the “actual” work size by anything smaller than the maximum device local work size, and were discussing on how to compute the “rounded up” work size.

The idea is this: given the worksize N and the local size L, we have to round N to the smallest multiple of L that is not smaller than N. This effectively means computing D = ceili(N/L) and then using D*L.

There are several ways to compute D, but on the computer, working only with integers and knowing that integer division always rounded down, what is the “best way”?

D = N/L + 1 works well if N is not a multiple of L, but gives us 1 more than the intended result if N *is* a multiple of L. So we want to add the extra 1 only if N is not a multiple. This can be achieved for example with

D = N/L + !!(N % L)

which leverages the fact that !! (double logical negation) turns any non-zero value into 1, leaving zero as zero. So we round *down* (which is what the integer division does) and then add 1 if (and only if) there is a reminder to the division.

This is ugly not so much because of the !!, but because the modulus operation % is slow.

1/n

#FluidX3D #CFD v3.2 is out! I've implemented the much requested #GPU summation for object force/torque; it's ~20x faster than #CPU #multithreading.
Horizontal sum in #OpenCL was a nice exercise - first local memory reduction and then hardware-supported atomic floating-point add in VRAM, in a single-stage kernel. Hammering atomics isn't too bad as each of the ~10-340 workgroups dispatched at a time does only a single atomic add.
Also improved volumetric #raytracing!
https://github.com/ProjectPhysX/FluidX3D/releases/tag/v3.2

My OpenCL-Benchmark now uses the dp4a instruction on supported hardware (#Nvidia Pascal, #Intel #Arc, #AMD RDNA, or newer) to benchmark INT8 tghroughput.
dp4a is not exposed in #OpenCL C, but can still be used via inline PTX assembly and compiler pattern recognition. Even Nvidia's compiler will turn the emulation implementation into dp4a, but in some cases does so with a bunch of unnecessary shifts/permutations on inputs, so better use inline PTX directly.
https://github.com/ProjectPhysX/OpenCL-Benchmark/releases/tag/v1.8

#FluidX3D #CFD v3.1 is out! I have updated the #OpenCL headers for better device specs detection via device ID and Nvidia compute capability, fixed broken voxelization on some #GPU​s and added a workaround for a CPU compiler bug that corrupted rendering. Also AMD GPUs will now show up with their correct name (no idea why they can't report it as CL_DEVICE_NAME like every other sane vendor and instead need CL_DEVICE_BOARD_NAME_AMD extension...)
Have fun!
https://github.com/ProjectPhysX/FluidX3D/releases/tag/v3.1

#NVIDIA #GeForce #RTX5090 #Linux #GPU Compute Performance #Benchmarks
When taking geo mean across 60+ benchmarks of #CUDA / #OptiX / #OpenCL / #Vulkan Compute, the GeForce RTX 5090 was delivering 1.42x the performance of GeForce #RTX4090. On performance-per-Watt GeForce RTX 5090 tended to deliver similar power efficiency to the RTX 4080/4090 graphics cards.
GeForce RTX 5090 Founders Edition was running cooler than many of the other Founders Edition graphics cards tested.
https://www.phoronix.com/review/nvidia-geforce-rtx5090-linux

How can I install #AMD iGPU #OpenCL drivers on #tuxedo_os I tried the deb from AMD but I get:

Unsupported OS: /etc/os-release ID 'tuxedo'

Any ideas? @tuxedocomputers #Linux #ubuntu

Boosts welcome!

A comparison of HPC-based quantum computing simulators using Quantum Volume

#CUDA #OpenCL #QuantumComputing #Overview

https://hgpu.org/?p=29643

Published another article about #Darktable with #OpenCL for #AMD #ROCm on #Debian (SID)... I finally got it working (again) :)

https://www.stranatesta.eu/tech/darktable-opencl-debian-sid-december-2024/

Dual #Intel Arc B580 go brrrr #OpenCL

This is the largest #CFD simulation ever on a single computer, the #NASA X-59 at 117 Billion grid cells. This video visualizes 7.6 PetaByte if volumetric data.

I did this simulation on 2x #Intel Xeon 6980P #HPC CPUs with 6TB MRDIMM memory at massive 1.7TB/s bandwidth. No #GPU​s required!

https://www.youtube.com/watch?v=K5eKxzklXDA

As a little gift to you all: #FluidX3D v3.0 is out now, enabling 31% larger resolution on CPUs/iGPUs with #OpenCL zero-copy buffers:
https://github.com/ProjectPhysX/FluidX3D/releases/tag/v3.0

*thinks about to which device to bring #OpenCL support next*

I'm thrilled to announce that #OpenCL support for #Qualcomm Adreno 600 and later landed and will be available in upcoming #Mesa3D 24.3! I really enjoyed being part of this effort and work on it with Dmitry, @karolherbst, and @robclark https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30835

@dexter Here's the AMD w/ CUDA support/library/api/shim/translation/thing that came up the other day:

> ZLUDA is a drop-in replacement for CUDA on non-NVIDIA GPU. ZLUDA allows to run unmodified CUDA applications using non-NVIDIA GPUs with near-native performance.

- https://vosen.github.io/ZLUDA/blog/zludas-third-life/
- https://github.com/vosen/ZLUDA

clang-20: argument '-Ofast' is deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations
#clang #programming #compiler #cli #optimization #level #c #cpp #o3 #opencl #llvm

Finding myself once again staring at a black screen, I remind myself: never trust AMDs #OpenCL implementation, and test your #GPU code on a remote machine.