Hi, lead author here. Thank you very much for posting our paper!
I have replied to some of the comments, and I am happy to answer questions and have further discussion about our work!
3 karma · joined October 5, 2021
I have replied to some of the comments, and I am happy to answer questions and have further discussion about our work!
Even with these layered tools, the host-GPU interop is still something that shader programming systems have to contend with directly, in contrast to "unified" systems like CUDA and C++ AMP in the GPU compute world. As you point out, translating C++ to GPU-compatible code is just one step in the process. Our work looks at the next step: once we can write both host and GPU shader code in C++, what's missing? What we discovered is that by merging the host and GPU halves together in C++, we inadvertently broke the critical shader specialization optimization. So our work presents a method to support shader specialization in a first class way, while also meeting our other design goals.
This work is definitely more on the practical or engineering side of things, and we believe it has significant research value as well. Our work echoes motivations from prior works, but the choice to target C++ and its limitations represents a fundamental difference compared to prior works that instead use uncommon/new languages with expanded feature sets. We believe that the synthesis of ideas from prior work, combined with our implementation strategy of co-opting existing language features, allows us to create a cohesive, C++-based system that is a novel contribution to the field.
Nevertheless, these types of "systems" papers are sometimes challenging to review, especially if reviewers are unfamiliar with systems research. The novelty comes from the act of building the system---it lets us see what "just works," see what doesn't (e.g., shader specialization in this case), and figure out solutions to the challenges that arise along the way.
I think Kayvon Fatahalian of Stanford University does a fantastic job of illustrating the value of systems papers here: https://graphics.stanford.edu/~kayvonf/notes/systemspaper/ and the structure of our paper is certainly influenced by this philosophy.
The ability to compile C++ code to GPU-executable kernels for use in shader programming is a massive undertaking, and we're glad that the Circle compiler is working to accomplish this task! Instead, our work focuses on the next layer: once we can generate both host- and GPU-compatible shader code from C++, what else is required to achieve useful unified shader programming?
Our work identifies shader specialization as a major missing piece when attempting to unify host and GPU shader code into C++. For reasons we discuss in the paper, current methods available in C++ to potentially support GPU code specialization are insufficient, and Circle does not add any language design provisions to allow dynamic logic in host code to influence compile-time specialization and selection of GPU code, which is central to supporting unified shader specialization. Our work aims to provide this support by co-opting C++ attributes and virtual functions.
Circle also adds other language features on top of C++, including some interesting new metaprogramming features. It may be possible to build a unified shader programming system using these new features, but since these new features are not part of C++, they would not allow us to meet our design goals. The end of Section 7 in our paper includes an expanded discussion of this topic.
I'm happy to answer any questions and have further discussion here!
The Rust GPU project is working to satisfy a necessary condition of unified shader programming in Rust: the ability to compile Rust code to GPU-executable kernels. However, in its current state, it does not provide interop between the host (CPU) code and GPU code in a unified way. Programmers still need to create separate host and GPU representations of parameters (and keep these two definitions in sync) and use API calls to communicate between the two halves of the code.
Similarly, Metal's GPU shader code is written in (a subset of) C++, but Metal does not meet our definition of a unified shader programming environment for the same reason.
Our work investigates the next step in this process: once we can translate host language X to GPU-compatible code, what else do we need to accomplish to unify the host and GPU halves of shader code into the same programming environment.
Adding C++ lambda support to shader programming would certainly be beneficial, but I don't think it, alone, would provide the modularity, composition, and GPU code specialization features necessary for an effective shader programming model.
That said, I am not an expert in SYCL, so if you have some ideas about how SYCL could meet our design goals, I would appreciate further feedback!