#OpenCL has a compiler flag -cl-fp32-correctly-rounded-divide-sqrt. If you don't pass this, then divisions and square roots are incorrectly rounded. Shouldn't this be the other way around? How many other flags to I need to pass in order for arithmetic to be correct?
We released an updated version of the OpenCL Intercept Layer yesterday, just in time for #IWOCL!
This release supports the latest OpenCL extensions, includes a bunch of performance improvements, and adds a bunch of new features, including the ability to capture an OpenCL kernel and replay it outside of an application for easier debugging.
How realistic can a #CFD simulation be? Here is a 1 billion cell #FluidX3D simulation of an impacting raindrop, fully raytraced in 8K. FluidX3D contains state-of-the-art volume-of-fluid and surface tension models for highly accurate free surface simulations. Combined with my own #OpenCL#raytracing engine, results are rendered on-the-fly at resolution as large as remaining #GPU VRAM can hold. 🖖😋💧📺 https://youtu.be/MmLNQIW_Sic
FluidX3D is on #GitHub: https://github.com/ProjectPhysX/FluidX3D
#HPC#CUDA#OpenCL#LAPACK
If you had to do a lot of linear least square solves, with potentially rank-deficient matrices, what would you use on a GPU? On CPUs, LAPACK's DGELSY does work, but most GPU libraries seem to not implement routines for rank-deficient matrices.
This is wild: #FluidX3D can "SLI" together 🔵 #Intel Arc A770 + 🟢 #Nvidia Titan Xp, pooling 12GB+12GB of their VRAM for one large 450M cell #CFD simulation. Top half on A770, bottom half on Titan Xp. They seamlessly communicate over PCIe. Performance is ~1.7x of what either #GPU could do on its own. 🖖😋🖥🔥 #OpenCL shows its true power here - one implementation works on literally all GPUs at full performance, even at the same time. Happy #SimulationFriday! https://youtu.be/PscbxGVs52o
Anyway, any OpenCL applications you want to see working on Rusticl and which aren't atm? Or in general? It's slowly getting into the state, where things "just work".
@VileLasagna Has a blog post on the relative speed of different #GPU compute frameworks on the same hardware and driver.
Tl;dr: on an #Nvidia card, with Nvidia drivers, #CUDA is the slowest, by far. Fastest is our old stalwart #OpenCL - almost twice as fast when used only for compute. #Vulcan is good, and the least affected by using the card for your desktop at the same time. Read it - it's good.
Passively participating in #Genuary2024 — Day 8 Chaotic System. In 2012/13 I designed an award-winning audioreactive brand identity system for Leeds College Of Music based on the DeJong strange attractor with tens and hundreds of millions of particles per frame. This massive almost 1 year project consisted of a Mac/PC desktop app (written in Clojure, OpenCL & OpenGL) for exploring the attractor, creating presets and scheduling render jobs for super hi-res print assets (which would take a hours to render and were the biggest image sizes I ever had to deal with, up to 3x3 meters @ 150 dpi). I also had to develop an entire AWS based ad-hoc render farm and asset & user management system for the school to generate personalized video assets, allowing each student to upload their own music, handle audio FFT analysis and beat detection/mapping (all in Clojure) and to create individual sound-responsive clips for their in-school digital signage system and for sharing on social media... Most key aspects were handled via various old thi.ng libraries (e.g. https://thi.ng/simplecl for OpenCL interop). The server app also handled transcoding to dozens of video formats (via ffmpeg) and semi-automatic provisioning of EC2 machines for render/transcoding jobs...
An example video is below (music: Heyoka, Blue Towel)
A week ago was the 1st anniversary of this solo instance & more generally of my fulltime move to Mastodon. A good time for a more detailed intro, partially intended as CV thread (pinned to my profile) which I will add to over time (also to compensate the ongoing lack of a proper website)... Always open to consulting offers, commissions and/or suitable remote positions...
Hi, I'm Karsten 👋 — indy software engineer, researcher, #OpenSource author of hundreds of projects (since ~1999), computational/generative artist/designer, landscape photographer, lecturer, outdoor enthusiast, on the ND spectrum. Main interest in transdisplinary research, tool making, exploring techniques, projects & roles amplifying the creative, educational, expressive and inspirational potential of (personal) computation, code as material, combining this with generative techniques of all forms (quite different to what is now called and implied by "generative AI").
Much of my own practice & philosophy is about #BottomUpDesign, interconnectedness, simplicity and composability as key enablers of emergent effects (also in terms of workflow & tool/system design). Been adopting a round-robin approach to cross-pollinate my work & learning, spending periods going deep into various fields to build up and combine experience in (A-Z order): API design, audio/DSP, baremetal (mainly STM32), computer vision/image processing, compiler/DSL/VM impl, databases/linked data/query engines, data structures impl, dataviz, fabrication (3DP, CNC, knit, lasercut), file formats & protocols (as connective tissue), "fullstack" webdev (front/back/AWS), generative & evolutionary algorithms/art/design/aesthetics/music, geometry/graphics, parsers, renderers, simulation (agents/CFD/particles/physics), shaders, typography, UI/UX/IxD...
Since 2018 my main endeavor has been https://thi.ng/umbrella, a "jurassic" (as it's been called) monorepo of ~185 code libraries, addressing many of the above topics (plus ~150 examples to illustrate usage). More generally, for the past decade my OSS work has been focused on #TypeScript, #C, #Zig, #WebAssembly, #Clojure, #ClojureScript, #GLSL, #OpenCL, #Forth, #Houdini/#VEX. Earlier on, mainly Java (~15 years, since 1996).
Formative years in the deep end of the #Atari 8bit demoscene (Chip Special Software) & game dev (eg. The Brundles, 1993), B&W dark room lab (since age 10), music production/studio (from 1993-2003), studied media informatics, moved to London initially as web dev, game dev (Shockwave 3D, ActionScript), interaction designer, information architect. Branched out, more varied clients/roles/community for my growing collection of computational design tools, which I've been continously expanding/updating for the past 20+ years, and which have been the backbone of 99% of my work since ~2006 (and which helped countless artists/designers/students/studios/startups). Creator of thi.ng (since 2011), toxiclibs (2006-2013), both large-scale, multi-faceted library collections. Early contributor to Processing (2003-2005, pieces of core graphics API).
Worked on dozens of interactive installations/exhibitions, public spaces & mediafacades (own projects and many collabs, several award winning), large-scale print on-demand projects (>250k unique outputs), was instrumental in creating some of the first generative brand identity systems (incl. cloud infrastructure & asset management pipelines), collaborated with architects, artists, agencies, hardware engineers, had my work shown at major galleries/museums worldwide, taught 60+ workshops at universities, institutions and companies (mainly in EMEA). Was algorithm design lead at Nike's research group for 5 years, working on novel internal design tools, workflows, methods of make, product design (footwear & apparel) and team training. After 23 years in London, my family decided on a lifestyle change and so currently based in the beautiful Allgäu region in Southern Germany.
Whenever I can, I try to end each lesson with a provocation.
When we finished our first trivial #OpenCL program, I showed them how the kernel runtime plus data transfer runtime actually made GPUs “not convenient”, as a prelude to illustrating the usefulness of memory pinning and buffer (un)mapping to improve data transfer efficiency and avoiding them when possible.
We're still working on that trivial program, so today I showed them how number of elements affects performance.
Got #TornadoVM installed and running on my local Linux laptop, a #Lenovo 14s Thinkpad with an 10th generation Intel® Core™ CPU and an integrated Intel® UHD graphics card.
Took a bit of futzing around with runtime dependencies, but the required packages (for Ubuntu Jammy) were: