9 ms·
Unified Shader Programming in C++
- kjgkjhfkjf 5y agoTo be honest, I'm disappointed that this is considered a suitable subject for academic enquiry.
- wk_end 5y agoWhy?
- adamdusty 5y agoWhen I was working on a game engine, I came across a few papers trying to do the same thing. I think it's more than worthy of academic study. It's no different than any other compiler research. The problem isn't just compiling C++ to glsl. The problem is taking c++ and allowing you to write your shader as part of your program. Right now, you essentially have 2 options: you can write one shader that does everything and use the actual data passed to it to conditionally run what you want, or you build a shader composition system that takes small chunks of code and pieces them together based on what data you want to pass to it. Thats overly simplified, but a kind of high level view. There are a few talks from bungie detailing the work they put into their shader system so that technical artists could have a smooth workflow. Ultimately, your engine can't handle custom shaders without the engine user also writing code for the cpu side, unless you have a AAA sized engine team that develops a compiler to achieve that.
- KerryASeitzJr 5y agoHi, lead author here. You're definitely getting at the core of the issue. An effective shader programming models needs to support modularity and composition of shader code, while also supporting GPU code specialization and interop between host and GPU code. Large game engines provide layered tools that aim to provide these features, and they are very useful especially for users who aren't experts in graphics programming (e.g., artists and technical artists). I'll use this opportunity to shamelessly plug our prior work, which explores these aspects of shader systems in more detail: https://dl.acm.org/doi/10.1145/3355089.3356554 https://dl.acm.org/doi/10.1145/3355089.3356554 (preprint here: https://escholarship.org/uc/item/2f8448n2 https://escholarship.org/uc/item/2f8448n2 ) 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.
- mshockwave 5y agoI kinda understand what OP want to say here: This work is IMO pretty valuable from an engineering perspective or as a generic project. But academic is an special (if not slightly weird) place -- an academic paper usually needs to demonstrate strong novelty (or extreme novelty if your reviewers are picky) on its idea. When you see the paper from this angle, it doesn't make significant difference from previous unified shader programming idea. In short, "creating something high quality using existing ideas" is usually pretty hard to get you a solid accept in tier 1 PL conferences. Don't get me wrong, this very point is also my biggest disappointment on academic area: I absolutely appreciate their breakthrough on new knowledge, but the fact that they underestimate some of engineering works that truly help our daily life just really piss me off.
- KerryASeitzJr 5y agoHi, lead author here. Thanks for your kind words on the value of our work! 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/ https://graphics.stanford.edu/~kayvonf/notes/systemspaper/ and the structure of our paper is certainly influenced by this philosophy.
- wrnr 5y agoMakepad does something simular with its universal shading language: https://makepad.dev/ https://makepad.dev/
- orbifold 5y agoThe circle compiler has this feature and many more, like CUDA, Vulkan support.
- ekelsen 5y agoCircle compiler ftw!
- KerryASeitzJr 5y agoHi, lead author here. The Circle compiler is certainly some great work! We cite it in Section 7 of our paper. 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!
- orbifold 5y agoI think shader specialisation is handled pretty well in circle. Since you can essentially run arbitrary C++ code at compile time, selection and specialisation of a shader can even depend on hardware specific benchmarks. There is an extensive repo with examples here: https://github.com/seanbaxter/shaders https://github.com/seanbaxter/shaders. One example decodes a sprite sheet stored as a png at compile time and creates a specialised compute shader for it. You can also easily implement a control UI based on reflection of uniform shader parameters. Anyways I understand that under different constraints (adherence to C++ standard, can't easily implement a whole C++ frontend and interpreter) this becomes much harder.
- sharmin123 5y agoThe Effective Positive Parenting Tips And Avoid Parenting Challenges: https://www.hackerslist.co/the-effective-positive-parenting-tips-and-avoid-parenting-challenges/ https://www.hackerslist.co/the-effective-positive-parenting-...
- billfruit 5y agoNot exact related, but is there a modern, widely used object oriented c++ wrapper for OpenGL? Why does OpenGL persist with a C style API instead of a more expressive one?
- Jasper_ 5y agoThere's no wrapper because a modern high level rendering engine doesn't expose raw graphics APIs to the user, and instead keeps it behind higher level structures like draw calls and render graphs. At that layer, you don't need the C++ API, in fact you want something to efficiently let you manage the OpenGL context state as directly as possible. And a C API is fine for that. Basically, the amount of code interfacing with OpenGL should be fairly minimal.
- Jare 5y agoC can interop with anything. There are higher level graphics libraries on top of OpenGL, Vulkan, Metal, WebGL & DirectX, for example bgfx or sokol, but IIRC they still go C style for the same reason. Then there are language-specific libraries that will be idiomatic, like wgpu for Rust. Finally, you reach entire very opinionated game engines at various levels (Unity, UE, Godot, etc).
- gavinray 5y agoRust also has this, from what I understand: https://github.com/EmbarkStudios/rust-gpu
- mhh__ 5y agodcompute!
- nicwilson 5y agolinks for the curious: https://github.com/libmir/dcompute/ https://github.com/libmir/dcompute/
- KerryASeitzJr 5y agoHi, lead author here. The Rust GPU project is certainly some great work! We cite it in Section 7 of our paper. 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.
- waynecochran 5y agoStrange the SYCL is never mentioned. It seems to meet the targets goals better by using C++ lambdas, ... https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:anatomy https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/s...
- deleted 5y ago[deleted]
- pjmlp 5y agoProbably because other than Intel with their DPC++ "improvements", almost no one cares that much.
- misnome 5y agoThis does unfortunately feel like the case. We've gone all-in on SYCL, mainly because of a pre-existing Intel relationship, but it never really seems to have gotten mindshare and e.g. never seems to have been dicussed here https://hn.algolia.com/?query=sycl https://hn.algolia.com/?query=sycl
- waynecochran 5y agoIt is a Khronos standard so someone must care -- its not like it is some backwater proprietary framework.
- oddity 5y agoWell, one of the authors is from NVIDIA, and the paper already mentions CUDA, and it's only to argue that CUDA is a good point of reference but doesn't do what the authors need it do (shader programming). SYCL doesn't add anything to that conversation other than being yet another example.
- nextaccountic 5y ago> SYCL doesn't add anything to that conversation other than being yet another example. It's important to cite prior work in academic papers, nonetheless
- KerryASeitzJr 5y agoHi, 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!