3 ms·

I think that's pretty consistent? If it takes one year for OpenGL ES2 coverage, not even optimization, it will probably take two more years at least for proper

I think that's pretty consistent? If it takes one year for OpenGL ES2 coverage, not even optimization, it will probably take two more years at least for proper optimized Vulkan/SPIR-V/OpenGL 4 support along with accelerated vidéo encode and decode support.

gjsman-1000 5y ago
True - but the 2024 cynics (as seen primarily on forums like Phoronix) doubted that there would be OpenGLES in this time frame.
- opencl 5y ago
  Those last few percent are a huge amount of work, they were at 93% in July. https://twitter.com/alyssarzg/status/1414354306157875204 https://twitter.com/alyssarzg/status/1414354306157875204
  - gjsman-1000 5y ago
    That is true and still concerning. The Asahi Linux defense is that only Rosenzweig has been working on it so far, while Martin and Sven have been working on other drivers. They will, in a few months, finish those up (or close enough) and then begin also attacking the GPU, which should then be a lot of progress quickly.
coldtea 5y ago
They don't implement OpenGL ES2, they figure out the GPU / graphics drivers interfaces / etc, and OpenGL ES2 then works as more features are made available. If they have coverage of the GPU, then Vulcan and so on will play for the features ES2 does. Besides you don't need support for all exotic features to run Linux with hw acceleration.
- sudosysgen 5y ago
  I'd say usable desktop hardware acceleration requires accelerated rendering in the browser and video decode acceleration. These tend to require pretty exotic features and still aren't implemented in a few PC graphics driver. OpenGL ES 2.0 is pretty simple in comparison, and you won't have to deal with undocumented features and so on. It's also not as simple as coverage, you also need good performance, which means you need a good optimizing compiler for the GPU architecture, and that's not obvious either. Unless they are using Apple's drivers? I don't know that they are. From reading her website it seems they are not.
  - GeekyBear 5y ago
    > It's also not as simple as coverage, you also need good performance, which means you need a good optimizing compiler for the GPU architecture, and that's not obvious either. Unless they are using Apple's drivers? I don't know that they are. She's been writing progress reports as she goes. This one is from back in May. >I’ve begun a Gallium driver for the M1, implementing much of the OpenGL 2.1 and ES 2.0 specifications. With the compiler and driver together, we’re now able to run OpenGL workloads like glxgears and scenes from glmark2 on the M1 with an open source stack. We are passing about 75% of the OpenGL ES 2.0 tests in the drawElements Quality Program used to establish Khronos conformance. To top it off, the compiler and driver are now upstreamed in Mesa! Gallium is a driver framework inside Mesa. It splits drivers into frontends, like OpenGL and OpenCL, and backends, like Intel and AMD. In between, Gallium has a common caching system for graphics and compute state, reducing the CPU overhead of every Gallium driver. The code sharing, central to Gallium’s design, allows high-performance drivers to be written at a low cost. For us, that means we can focus on writing a Gallium backend for Apple’s GPU and pick up OpenGL and OpenCL support “for free”. https://rosenzweig.io/blog/asahi-gpu-part-4.html https://rosenzweig.io/blog/asahi-gpu-part-4.html
    - sudosysgen 5y ago
      Yes. Simply covering these features will provide basic support for many features. That doesn't, however, means that performance will automatically be sufficient. It also remains to be seen if the more complex featureset of OpenGL 3.1 is as straightforward to cover efficiently. I'm not saying it won't happen. I'm just saying that we shouldn't underestimate how much work there is. Even with the help of Mesa and years of effort, the nouveau backend for NVidia cards is still barely satisfactory even for day to day tasks, it's OpenGL performance is very poor even for basic applications. It's really not as simple as just coverage in practice.

gjsman-1000 5y ago

True - but the 2024 cynics (as seen primarily on forums like Phoronix) doubted that there would be OpenGLES in this time frame.

opencl 5y ago
Those last few percent are a huge amount of work, they were at 93% in July. https://twitter.com/alyssarzg/status/1414354306157875204 https://twitter.com/alyssarzg/status/1414354306157875204
- gjsman-1000 5y ago
  That is true and still concerning. The Asahi Linux defense is that only Rosenzweig has been working on it so far, while Martin and Sven have been working on other drivers. They will, in a few months, finish those up (or close enough) and then begin also attacking the GPU, which should then be a lot of progress quickly.

coldtea 5y ago

They don't implement OpenGL ES2, they figure out the GPU / graphics drivers interfaces / etc, and OpenGL ES2 then works as more features are made available. If they have coverage of the GPU, then Vulcan and so on will play for the features ES2 does. Besides you don't need support for all exotic features to run Linux with hw acceleration.

sudosysgen 5y ago
I'd say usable desktop hardware acceleration requires accelerated rendering in the browser and video decode acceleration. These tend to require pretty exotic features and still aren't implemented in a few PC graphics driver. OpenGL ES 2.0 is pretty simple in comparison, and you won't have to deal with undocumented features and so on. It's also not as simple as coverage, you also need good performance, which means you need a good optimizing compiler for the GPU architecture, and that's not obvious either. Unless they are using Apple's drivers? I don't know that they are. From reading her website it seems they are not.
- GeekyBear 5y ago
  > It's also not as simple as coverage, you also need good performance, which means you need a good optimizing compiler for the GPU architecture, and that's not obvious either. Unless they are using Apple's drivers? I don't know that they are. She's been writing progress reports as she goes. This one is from back in May. >I’ve begun a Gallium driver for the M1, implementing much of the OpenGL 2.1 and ES 2.0 specifications. With the compiler and driver together, we’re now able to run OpenGL workloads like glxgears and scenes from glmark2 on the M1 with an open source stack. We are passing about 75% of the OpenGL ES 2.0 tests in the drawElements Quality Program used to establish Khronos conformance. To top it off, the compiler and driver are now upstreamed in Mesa! Gallium is a driver framework inside Mesa. It splits drivers into frontends, like OpenGL and OpenCL, and backends, like Intel and AMD. In between, Gallium has a common caching system for graphics and compute state, reducing the CPU overhead of every Gallium driver. The code sharing, central to Gallium’s design, allows high-performance drivers to be written at a low cost. For us, that means we can focus on writing a Gallium backend for Apple’s GPU and pick up OpenGL and OpenCL support “for free”. https://rosenzweig.io/blog/asahi-gpu-part-4.html https://rosenzweig.io/blog/asahi-gpu-part-4.html
  - sudosysgen 5y ago
    Yes. Simply covering these features will provide basic support for many features. That doesn't, however, means that performance will automatically be sufficient. It also remains to be seen if the more complex featureset of OpenGL 3.1 is as straightforward to cover efficiently. I'm not saying it won't happen. I'm just saying that we shouldn't underestimate how much work there is. Even with the help of Mesa and years of effort, the nouveau backend for NVidia cards is still barely satisfactory even for day to day tasks, it's OpenGL performance is very poor even for basic applications. It's really not as simple as just coverage in practice.