[almostgotcaught]

Thread, group, workgroup.

There you go you've hit basically two of 3 completely (AMD and Vulkan) and are close enough to CUDA that people would get it.

I have no idea what a plane connotes and a cube literally gives a distinct enough picture from block that I will be continuously reminding myself of the mapping.

What you did was pointless - you assigned new words to objects that you don't own and now your conceptual framework is askew from the actual underlying (true) conceptual framework.

> CubeCL to CPU

There is zero affinity between GPU programing models and multicore CPU programing models. If you don't believe me go ask the OpenMP people how they're doing supporting GPUs.

[nathanielsimard]

Well we can agree to disagree, CubeCL also has the concept of instruction parallelism, which would be used to target simd instructions on CPU. Our algorithms are normally flexible on both the plane size and the line size, adapting to the hardware with comptime logique. You are free to dislike the naming, but imo a mix of multiple APIs is worse than something new.

[gyrovagueGeist]

For people who are interested Kokkos (a C++ library for writing portable kernels) also has a naming scheme for hierarchical parallelism. They use ThreadTeam, Thread (for individual threads within a group), and ThreadVector (for per thread SIMD).

Just commenting to share, personally I have no naming preference but the hierarchal abstractions in general are incredibly useful.

[almostgotcaught]

> Our algorithms are normally flexible on both the plane size and the line size

Congrats - I have no idea what this means lol.

[syl20bnr]

It will make more sense once you start using CubeCL. There's now a CubeCL book available: https://burn.dev/books/cubecl/.

It does come with some mental overhead, but let’s be honest, there’s no objectively “good” choice here without introducing bias toward a specific vendor API.

Learning the core concepts takes effort, but if CubeCL is useful for your work, it’s definitely worth it.