7 ms·

That doesn't attempt to add for example compute shader support to GPUs that don't support it. Or FP16 support. Or geometry shaders. Or VBOs. And for example fr

That doesn't attempt to add for example compute shader support to GPUs that don't support it. Or FP16 support. Or geometry shaders. Or VBOs. And for example from that Gallium page: > The new driver interface will assume the presence of programmable vertex/fragment shaders and flexible memory objects. It essentially was a hardware HAL rev, and did not attempt to support hardware that couldn't be updated to the new HAL. Which is actually the Linux way for most all hardware. Either the driver stays up to date, or the hardware is abandoned and no longer supported. The push there is to upstream the driver so that the community can maintain it, but the end result is more or less the same. It either gets updated, or it's no longer supported. Linux has never had and actively rejects attempts to introduce any form of a driver API/ABI. In terms of policy then Linux basically provides 0 days of support for anything that isn't open source & upstreamed. Even 2 years would be an unfathomably long support window. But even ignoring all that, GPUs are above average in flexibility for hardware drivers. Compare to something like a camera ISP. A huge complaint of fragmentation for app devs on Android is around the camera, because it turns out you just can't layer a lower level, more flexible API on top of a higher level, more restricted HAL. That's the Camera1 vs. Camera2 API mess on Android in a nutshell.

StillBored 5y ago
Well, i wasn't going to respond, because again IMHO your mostly wrong. I suggest you look at llvmpipe (for shader emulation). Because abstractions can be extended both to higher level concepts as well as lower. The whole concept of shaders were bolted onto the GL specs. The fact that a certain ecosystem is unable to extend their abstractions, as you mention with the camera situation, is less about abstractions and more about the mindset of that ecosystem. I'm fairly sure that I can design an API that provides much of what one gets with camera2 in a way that allows most apps to continue to behave like nothing changed, while allowing newer apps that need that functionality to request it of the existing API, while also maintaining ABI compatibility with older drivers, and allowing newer drivers to provide said extensions either via an extension mechanism, or alternatively a shim that layers the older API on top of a newer driver API (and therefor providing two driver ABIs one for older drivers and a newer one for newer drivers). The vulcan/GL situation is informative here. Having SW or HW that supports one or the other doesn't preclude the opposite. And things like FP16, which are used mostly to provide higher perf/efficiency machine learning, already usually have some kind of abstraction in place to just use FP32 in places where FP16 isn't available. The point being that the "success" of the android/arm disposable software/HW model shouldn't imply its not possible to build abstraction, and extend them.
- kllrnohj 5y ago
  The thing you're still stuck on is the idea that you can update the driver. That's the part that's frozen in time. Whatever abstraction/API you happened to use for it, that's what you're stuck with. You (often) can't then bolt on newer features onto that old driver without changing the driver. The API that apps use, that's irrelevant. That's "trivially" kept stable. It's the API that hardware uses, and adding features to it retroactively that's extremely difficult if possible at all. In the cases where it is possible to do layering, it's almost always in the reverse direction. Such as ANGLE implementing WebGL/GLES onto things more powerful & flexible than GLES is. > And things like FP16, which are used mostly to provide higher perf/efficiency machine learning I wasn't clear on this but I was referring to FP16 FBOs, which was something GLES 3 added that GLES 2 didn't have (instead of 8888 FBOs)
  - StillBored 5y ago
    No, thats my point, its possible to shim say 3d sound into a driver/HW stack that doesn't support it via software. In the cases that you truly need a new HW feature, you assure the userspace API your providing to applications doesn't fail when that feature doesn't exist. AKA you don't make your entire software stack dependent on that feature, you provide fallbacks. That way the old HW/driver that doesn't have the new feature continues to work. AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible. Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced. EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.
    - kllrnohj 5y ago

StillBored 5y ago

Well, i wasn't going to respond, because again IMHO your mostly wrong. I suggest you look at llvmpipe (for shader emulation). Because abstractions can be extended both to higher level concepts as well as lower. The whole concept of shaders were bolted onto the GL specs. The fact that a certain ecosystem is unable to extend their abstractions, as you mention with the camera situation, is less about abstractions and more about the mindset of that ecosystem. I'm fairly sure that I can design an API that provides much of what one gets with camera2 in a way that allows most apps to continue to behave like nothing changed, while allowing newer apps that need that functionality to request it of the existing API, while also maintaining ABI compatibility with older drivers, and allowing newer drivers to provide said extensions either via an extension mechanism, or alternatively a shim that layers the older API on top of a newer driver API (and therefor providing two driver ABIs one for older drivers and a newer one for newer drivers). The vulcan/GL situation is informative here. Having SW or HW that supports one or the other doesn't preclude the opposite. And things like FP16, which are used mostly to provide higher perf/efficiency machine learning, already usually have some kind of abstraction in place to just use FP32 in places where FP16 isn't available. The point being that the "success" of the android/arm disposable software/HW model shouldn't imply its not possible to build abstraction, and extend them.

kllrnohj 5y ago
The thing you're still stuck on is the idea that you can update the driver. That's the part that's frozen in time. Whatever abstraction/API you happened to use for it, that's what you're stuck with. You (often) can't then bolt on newer features onto that old driver without changing the driver. The API that apps use, that's irrelevant. That's "trivially" kept stable. It's the API that hardware uses, and adding features to it retroactively that's extremely difficult if possible at all. In the cases where it is possible to do layering, it's almost always in the reverse direction. Such as ANGLE implementing WebGL/GLES onto things more powerful & flexible than GLES is. > And things like FP16, which are used mostly to provide higher perf/efficiency machine learning I wasn't clear on this but I was referring to FP16 FBOs, which was something GLES 3 added that GLES 2 didn't have (instead of 8888 FBOs)
- StillBored 5y ago
  No, thats my point, its possible to shim say 3d sound into a driver/HW stack that doesn't support it via software. In the cases that you truly need a new HW feature, you assure the userspace API your providing to applications doesn't fail when that feature doesn't exist. AKA you don't make your entire software stack dependent on that feature, you provide fallbacks. That way the old HW/driver that doesn't have the new feature continues to work. AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible. Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced. EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.
  - kllrnohj 5y ago