[HN Gopher] Unified Shader Programming in C++
___________________________________________________________________
Unified Shader Programming in C++
Author : matt_d
Score : 66 points
Date : 2021-10-03 17:14 UTC (5 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| sharmin123 wrote:
| The Effective Positive Parenting Tips And Avoid Parenting
| Challenges: https://www.hackerslist.co/the-effective-positive-
| parenting-...
| gavinray wrote:
| Rust also has this, from what I understand:
| https://github.com/EmbarkStudios/rust-gpu
| mhh__ wrote:
| dcompute!
| waynecochran wrote:
| Strange 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/s...
| pjmlp wrote:
| Probably because other than Intel with their DPC++
| "improvements", almost no one cares that much.
| [deleted]
| billfruit wrote:
| Not 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?
| junon wrote:
| https://github.com/bkaradzic/bgfx
| Jasper_ wrote:
| There'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.
| [deleted]
| nih0 wrote:
| theres magnum.graphics but going with an opengl loader is
| always better imo
| Game_Ender wrote:
| https://magnum.graphics
|
| Supports WASM and WebGL too!
| pjmlp wrote:
| Because Khronos just cannot move their mindset away from C.
|
| It took NVidia beating them to the ground for OpenCL to ever
| consider anything other than C and create SPIR.
|
| Then the existing C++ bindings for Vulkan were originally
| created by NVidia (again).
|
| Now ANARI is yet again a C API, they just cannot move beyond C.
| Jare wrote:
| C 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).
| pjmlp wrote:
| Metal and DirectX are based on C++, thankfully.
| my123 wrote:
| The exposed API for Metal is Obj-C, and the one for DirectX
| is using COM.
|
| (for shaders, MSL is a C++ dialect, but HLSL isn't)
| pjmlp wrote:
| Thanks for being pedantic, none of them is C.
| vvanders wrote:
| Pedantically, none of them are C++ either.
| EamonnMR wrote:
| You may enjoy the OGRE. https://www.ogre3d.org/
| mikepurvis wrote:
| Ogre is the renderer for a number of robotics projects, like
| rviz (robot visualization) and Gazebo (robot simulation). I
| don't know that either of those necessarily showcase it in
| the best possible light, but more just to say that it has a
| rich history serving in a variety of cross-platform use
| cases.
| Const-me wrote:
| If you have relatively new GL, this one is good:
| https://diligentgraphics.com/diligent-engine/
| spacechild1 wrote:
| There's https://openframeworks.cc/. It's basically the C++
| equivalent to https://processing.org/. Unfortunately, it's not
| really a library but rather a complete app framework, but it
| shows how a C++ wrapper API could look like. It definitely
| makes OpenGL programming easier and more fun.
| Procedural wrote:
| > Unfortunately, it's not really a library
|
| I made it a library with a single header:
| https://github.com/redgpu/framework
| spacechild1 wrote:
| Interesting. Where is the source code?
| forrestthewoods wrote:
| > instead of a more expressive one?
|
| I would not consider a C++ API particularly more expressive
| than a C API.
|
| RAII handles are nice. But that's about all the expressiveness
| you get from C++ at the API level.
|
| Languages that provide expressiveness generally do so at the
| implementation level, in my experience.
| dkersten wrote:
| > RAII handles are nice.
|
| If that's all you want, its not hard to write your own RAII
| wrapper for things anyway.
| forrestthewoods wrote:
| Agreed 100%. I quite like C APIs. They're simple, elegant,
| and can wrapped with RAII or your preferred style.
|
| A C++ API imposes its style on you. Usually badly. Never
| mind the ABI issues.
|
| Most interfaces could be improved by re-writing them in C.
| I can't say the same for the inverse.
|
| That said, OpenGL is a terrible API that is nearly
| impossible to use correctly. But neither C nor C++ have
| much impact on its horrifically stateful architecture.
| SubjectToChange wrote:
| C++ APIs are made far better by templates (and soon
| concepts), smart pointers, objects, better type checking,
| etc, not just RAII. C-style APIs really can't compete,
| IMO.
|
| > Never mind ABI issues.
|
| A C ABI is far more brittle than a C++ one.
| neutronicus wrote:
| Let's play "who's supposed to call 'free' on this
| pointer"!!!
| maccard wrote:
| And which free do you call? Do you call "free",
| "my_free", "3rdparty_typea_free" or
| "3rdparty_typeb_free"?
| forrestthewoods wrote:
| Uhhhh no.
|
| A C API can called by every language under the sun. C is
| the lingua franca of computer science.
|
| A C++ API can't even be reliably called by other C++
| programs. If I produce a shared library with C API it can
| be used broadly and easily. If I produce a shared library
| with a C++ it can only be used by C++ programs compiled
| with precisely the same settings.
|
| Providing a C++ API really just means "compile this
| entire library from source". I do indeed compile a lot of
| great third-party C++ code from source. That's not always
| possible or even desirable.
|
| If I need to use that code from a different language -
| for example C# for Unity or matlab for data science -
| then that C++ API is worthless and needs to be wrapped
| with a C API.
|
| I've recently been integrating some C++ libraries into
| C++ based Unreal Engine. It's easier to integrate a C API
| with Unreal C++ than it is to integrate random C++
| project with C++ based Unreal.
|
| The fact that C++ doesn't have a standard build system
| doesn't help. Integrating a C++ library to compile from
| source requires adapting random build system A with your
| build system B. There's a reason C++ projects love
| single-header (or single header + single cpp) C++
| libraries with no additional dependencies. Because they
| don't require jumping through a million hoops.
| maccard wrote:
| I disagree; type safety is something that is missing from
| almost every C api I've used; you end up with opaque handles
| that are just integers that can be easily misused. Consider
| the glBufferSubData method [0] - 2 of 4 of those parameters
| are really just integers that the programmer needs to know
| about, that the compiler won't check,and the last two are
| tightly coupled and not type safe; thetes nothing stopping
| you from passing an array of doubles (or whatever pointer you
| have lying around).
|
| Opengl also gets away with because you're almost always
| working with either floats or integers (for say index
| buffers) but once you start dealing with containers of
| containers, a C api ends up really messy with everything
| being an "object" and having to call
| function_str(my_obj_handle) with the correct handle - see
| sentry's api [1] for an example of what this looks like.
|
| A C++ api for OpenGL would allow for type safe flags, type
| and bounds checked buffers, RAII handles with all the good
| (and granted, bad) that comes with them.
|
| [0] https://www.khronos.org/registry/OpenGL-
| Refpages/gl4/html/gl...
|
| [1] https://github.com/getsentry/sentry-native
| pjmlp wrote:
| Metal, DirectX, GX2, LibGNMX prove otherwise.
| wffurr wrote:
| https://github.com/google/ion as used by Google Earth.
| integricho wrote:
| pure opengl wrapper: https://github.com/cginternals/globjects
___________________________________________________________________
(page generated 2021-10-03 23:00 UTC)