4 ms·

Well of course, for somethings it becomes a least common denominator, but even for GPU's in the past the idea was that it was possible to use something like Mes

Well of course, for somethings it becomes a least common denominator, but even for GPU's in the past the idea was that it was possible to use something like Mesa as the baseline and then accelerate the important/critical functionality in hardware. The original DX API was also designed like this. Its only once the market became basically a duopoly that the expectations shifted. Frankly, having a solid software reference model/fallback path likely makes peoples jobs easier because its easier to track down bugs by doing a/b testing. Oh, and BTW, you can likely boot your linux machine without your graphics card driver, and it will still be able to run your desktop/etc and simple openGL/etc applications like glxgears. How is that, because linux can and does fallback to software emulation, using... mesa.

kllrnohj 5y ago
No, that's not how that works. You can have an entirely software emulation or stub of a device, but that's not the same as more like a polyfill. Mesa will not emulate just the gap between your hardware and the latest feature set. You either get hardware with whatever it has, or only software emulated. It's complete unacceptable for everyone if an os update suddenly means your GPU is entirely unused because it doesn't support some new extension or feature, so now you're stuck with only CPU emulation. That's not a viable solution.
- StillBored 5y ago
  ? I'm not sure where your point is.. and read directly is false: You should read: https://www.freedesktop.org/wiki/Software/gallium/ https://www.freedesktop.org/wiki/Software/gallium/ for example: "The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn't map well to hardware capabilities. " And on and on... This doesn't mean that all the extensions exist for any piece of hardware, only that there is a pretty solid baseline. Its why I can run a gforce 7600 (which I was messing with a few days back) with a fairly recent rolling linux distro and it continues to work, and provide some level of acceleration. And while i'm at it: https://mesamatrix.net/ https://mesamatrix.net/
  - kllrnohj 5y ago
    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

No, that's not how that works. You can have an entirely software emulation or stub of a device, but that's not the same as more like a polyfill. Mesa will not emulate just the gap between your hardware and the latest feature set. You either get hardware with whatever it has, or only software emulated. It's complete unacceptable for everyone if an os update suddenly means your GPU is entirely unused because it doesn't support some new extension or feature, so now you're stuck with only CPU emulation. That's not a viable solution.

StillBored 5y ago
? I'm not sure where your point is.. and read directly is false: You should read: https://www.freedesktop.org/wiki/Software/gallium/ https://www.freedesktop.org/wiki/Software/gallium/ for example: "The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn't map well to hardware capabilities. " And on and on... This doesn't mean that all the extensions exist for any piece of hardware, only that there is a pretty solid baseline. Its why I can run a gforce 7600 (which I was messing with a few days back) with a fairly recent rolling linux distro and it continues to work, and provide some level of acceleration. And while i'm at it: https://mesamatrix.net/ https://mesamatrix.net/
- kllrnohj 5y ago
  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.