4 ms·

> 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

> 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
  Nouveau actually doesn't count as a good reference, because NVIDIA actually locked-out reclocking support from any firmware that is not NVIDIA-signed starting with the GTX 900 series. This means that if you are running any form of unsigned driver (which would be any open-source driver such as Nouveau) on those cards, the chip will run at the slowest possible performance tier, and won't allow the firmware to crank the speed up. Only the signed NVIDIA driver can change the GPU speed, which is basically mandatory for a driver to be useful. So - don't blame Nouveau for being behind, NVIDIA has made it so that open-source drivers are almost useless. In which case, why bother with improving Nouveau when the performance is going to be just terrible?
  - jcheng 5y ago
    Wow, why would they go out of their way to do that? Even with my most cynical hat on, I can’t think of how this is in their self interest. Oh, is it to ensure nerfing of FP64 performance for their consumer cards? Is that done at the driver level?
    - sudosysgen 5y ago
      I am pretty sure it's to prevent people from overclocking their cards more than NVidia deems safe for the sales of their most expensive cards.
      - ComputerGuru 5y ago
        If that were the case then manually setting the clock speed would be supported but it would lock out any speeds higher than the OEM configuration.
        sudosysgen 5y ago
        Not quite, no. Even manually setting the clock rate would allow for performance improvement as you could lock the card at its boost clock or at least prevent downclocking under load. The only lockout solution is to lock speeds to the base clock completely.
        ComputerGuru 5y ago
        It depends on how the card’s speed governor works. Do you set a desired clock rate and then the firmware tries to hold that speed dependent on factors like core temperature or do you set a hard value and the firmware holds that come hell or high water?
        sudosysgen 5y ago
        From how it used to work, the actual frequency was dependent on both the driver and firmware, though the driver used to and probably still can force a certain frequency.

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
Nouveau actually doesn't count as a good reference, because NVIDIA actually locked-out reclocking support from any firmware that is not NVIDIA-signed starting with the GTX 900 series. This means that if you are running any form of unsigned driver (which would be any open-source driver such as Nouveau) on those cards, the chip will run at the slowest possible performance tier, and won't allow the firmware to crank the speed up. Only the signed NVIDIA driver can change the GPU speed, which is basically mandatory for a driver to be useful. So - don't blame Nouveau for being behind, NVIDIA has made it so that open-source drivers are almost useless. In which case, why bother with improving Nouveau when the performance is going to be just terrible?
- jcheng 5y ago
  Wow, why would they go out of their way to do that? Even with my most cynical hat on, I can’t think of how this is in their self interest. Oh, is it to ensure nerfing of FP64 performance for their consumer cards? Is that done at the driver level?
  - sudosysgen 5y ago
    I am pretty sure it's to prevent people from overclocking their cards more than NVidia deems safe for the sales of their most expensive cards.
    - ComputerGuru 5y ago
      If that were the case then manually setting the clock speed would be supported but it would lock out any speeds higher than the OEM configuration.
      - sudosysgen 5y ago
        Not quite, no. Even manually setting the clock rate would allow for performance improvement as you could lock the card at its boost clock or at least prevent downclocking under load. The only lockout solution is to lock speeds to the base clock completely.
        ComputerGuru 5y ago
        It depends on how the card’s speed governor works. Do you set a desired clock rate and then the firmware tries to hold that speed dependent on factors like core temperature or do you set a hard value and the firmware holds that come hell or high water?
        sudosysgen 5y ago
        From how it used to work, the actual frequency was dependent on both the driver and firmware, though the driver used to and probably still can force a certain frequency.