3 ms·

> it seems quite viable to implement 2D rendering directly on GPU, with very promising quality and performance. I guess all agree that GPU rendering is the fut

> it seems quite viable to implement 2D rendering directly on GPU, with very promising quality and performance. I guess all agree that GPU rendering is the future. Yet, I'm still in favor for libraries that abstracts the actual renderer so it could fallback if needed. Especially when future and past conflicts. I come from audio development where people use plug-ins (dynamic libs) that loads on a host that provides native OS window you compose. Cross-platform is pretty vital so there are frameworks to target macOS, Windows, iOS (and sometimes Android & Linux). Here is a real life scenario that many audio developers are currently at: - you had a product with UI that needed to show 'real-time' visualization of signal - Analyzer (let's say FFT). - eventually you went the OpenGL way (because it was the right way in 2010...) you've written shaders. - it worked great on macOS and ok on most Windows machines (some old machines had limited or broken OpenGL within their drivers). - Apple deprecates OpenGL in favor of Metal... So now what was "modern" 9 years ago requires compete re-write. if there was an abstraction layer it might be minor changes and switching to new Metal renderer instead of the OpenGL one. In comparison, The native/cpu C++ code for the same product proven to be much more future proof and only required simple maintenance. It is indeed important work. but I guess targeting Vulkan is better especially when there are libs like MoltenVK. I guess the question is how much portability is important factor vs optimal performance.

Const-me 7y ago
> what was "modern" 9 years ago requires compete re-write. Have you thought about porting to GLES (shouldn't be that hard if you already have GL shaders), and using MoltenGL (apple) and ANGLE (windows)? AFAIK they both work reasonably well in practice. > I guess targeting Vulkan is better Vulkan support is improving but I’m not sure it’s ready yet. For Intel GPUs, only supported on Windows starting from Skylake (2015). > the question is how much portability is important factor vs optimal performance I think portable and fast cross-platform GUI is possible, just expensive to implement and especially support. Commercial game engines like Unity or Unreal optimize both at the same time, and they support low-spec platforms like mobile phones. When Microsoft wanted fast rich GUI portable across their platforms, they’ve built XAML. When Google wanted the same, they acquired Skia and built Chromium and now Flutter on top.
enqk 7y ago
bgfx is such a layer: https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx It exposes a common API to 3d GPU resources and implements it in terms of native backends.
zackmorris 7y ago
I've been through the same iterations you talked about, writing game graphics in MacOS Classic QuickDraw, then OS X Cocoa, then OpenGL, then ES2, now Unity... IMHO this is all going the wrong direction. I'm strongly against SIMD as a pattern because it makes things hard to generalize. The fact that we don't even know the architectures of the video cards we use every day is a huge red flag. I mean, that's the point we're trying to get to with abstractions, but SIMD exacerbated the pain by being so opinionated. The reason all of this is going in such strange (informal) directions is that video cards are proprietary and the money is in photorealistic rasterization. It's working along one branch of the tree of possible architectures. Then CUDA and TensorFlow etc are attempts to overlay other narrow generalizations over that and IMHO aren't nearly as good of approaches as MATLAB/Octave/Erlang/Go, etc. I've said this many times, but I'd prefer to have an array of general purpose CPUs, at least 256 and their number should roughly double in a predictable way every year or two. Then we could have abstractions over that that handle data locality or cache coherency (if needed... it most likely isn't). A chip like that would be trivial to use for ray tracing, for example. We're going to continue seeing this uninspired churn burning out developers until there is a viable high-core CPU to compete with GPUs.

Const-me 7y ago

> what was "modern" 9 years ago requires compete re-write. Have you thought about porting to GLES (shouldn't be that hard if you already have GL shaders), and using MoltenGL (apple) and ANGLE (windows)? AFAIK they both work reasonably well in practice. > I guess targeting Vulkan is better Vulkan support is improving but I’m not sure it’s ready yet. For Intel GPUs, only supported on Windows starting from Skylake (2015). > the question is how much portability is important factor vs optimal performance I think portable and fast cross-platform GUI is possible, just expensive to implement and especially support. Commercial game engines like Unity or Unreal optimize both at the same time, and they support low-spec platforms like mobile phones. When Microsoft wanted fast rich GUI portable across their platforms, they’ve built XAML. When Google wanted the same, they acquired Skia and built Chromium and now Flutter on top.

enqk 7y ago

bgfx is such a layer: https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx It exposes a common API to 3d GPU resources and implements it in terms of native backends.

zackmorris 7y ago

I've been through the same iterations you talked about, writing game graphics in MacOS Classic QuickDraw, then OS X Cocoa, then OpenGL, then ES2, now Unity... IMHO this is all going the wrong direction. I'm strongly against SIMD as a pattern because it makes things hard to generalize. The fact that we don't even know the architectures of the video cards we use every day is a huge red flag. I mean, that's the point we're trying to get to with abstractions, but SIMD exacerbated the pain by being so opinionated. The reason all of this is going in such strange (informal) directions is that video cards are proprietary and the money is in photorealistic rasterization. It's working along one branch of the tree of possible architectures. Then CUDA and TensorFlow etc are attempts to overlay other narrow generalizations over that and IMHO aren't nearly as good of approaches as MATLAB/Octave/Erlang/Go, etc. I've said this many times, but I'd prefer to have an array of general purpose CPUs, at least 256 and their number should roughly double in a predictable way every year or two. Then we could have abstractions over that that handle data locality or cache coherency (if needed... it most likely isn't). A chip like that would be trivial to use for ray tracing, for example. We're going to continue seeing this uninspired churn burning out developers until there is a viable high-core CPU to compete with GPUs.