[HN Gopher] "With those changes we're up to a 94% pass rate for ...
___________________________________________________________________
"With those changes we're up to a 94% pass rate for dEQP-GLES2"
Author : mmastrac
Score : 59 points
Date : 2021-12-17 17:54 UTC (1 days ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| tttyyyttt wrote:
| Impressive work from a very talented guy. Nice to see such good
| progess on this.
| dimensi0nal wrote:
| really?
|
| making an account just to post this?
| tttyyyttt wrote:
| Relax, I'm just complimenting his fine work.
| selectodude wrote:
| And making the decision to be a prick about her gender.
| tttyyyttt wrote:
| It's simply an honest compliment.
| gjsman-1000 wrote:
| "Implementing the GPU is the hard part."
|
| "It will take Asahi Linux years to get graphical acceleration."
|
| "Maybe they'll have graphics figured out by 2024 if they are
| lucky."
|
| Doubters gonna doubt. OpenGLES 2 for Asahi Linux on the M1, 94%
| conformity, just 1 year later.
| whateveracct wrote:
| Laymen programmers vastly overestimate systems work because
| they mythologize it.
|
| It's just attitude & elbow grease at the end of the day, and
| Asahi Linux clearly had plenty of both of those! Cheers.
| acchow wrote:
| Will this follow the 80/20 rule?
| ZiiS wrote:
| Yes they have done 94% of the work, only another 94% to
| completion.
| sudosysgen wrote:
| 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 video
| encode and decode support.
| gjsman-1000 wrote:
| True - but the 2024 cynics (as seen primarily on forums like
| Phoronix) doubted that there would be OpenGLES in this time
| frame.
| opencl wrote:
| Those last few percent are a _huge_ amount of work, they
| were at 93% in July.
|
| https://twitter.com/alyssarzg/status/1414354306157875204
| gjsman-1000 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| sudosysgen wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There are a lot of issues beyond reclocking, as we both
| know. Even before the reclocking issues, nouveau was not
| up to par despite years of work, and it is still far
| behind on cards with reclocking.
|
| The point I was making is that mere coverage is not
| enough for satisfactory performance. If it was the case,
| nouveau would have good performance on cards with
| reclocking support.
|
| It doesn't, because it takes a lot of work on the backend
| to get good performance.
| rrss wrote:
| this is great progress and Alyssa Rosenzweig is awesome, but
| afaik the gpu is not usable from Linux yet because the kernel
| driver is not yet written.
|
| the asahi team is very talented, but I don't think their
| progress means building a software stack for an undocumented
| gpu is not difficult.
| gjsman-1000 wrote:
| According to Hector Martin, writing the kernel driver will be
| easy as "all the magic happens in userspace." So even though
| the driver is running in userspace on macOS it won't be that
| much work to run in Linux, apparently.
| [deleted]
| phkahler wrote:
| I'm still concerned about that weird back and forth between
| driver and firmware that she talked about in one of the blog
| posts. Not really a stable API it seems.
| gjsman-1000 wrote:
| They said it's no problem - just use a fixed version of the
| macOS Display Controller firmware of your choice. For
| example, they might target the macOS 12.1 version of the
| firmware, maybe upgrade to the macOS 12.4 version a year
| later... It's not stable but it's easily made stable.
| phkahler wrote:
| >> They said it's no problem - just use a fixed version of
| the macOS Display Controller firmware of your choice.
|
| Is that really an option? Can we drop in the binary blob at
| will, or will it break if Apple pushes an update?even if
| that's the case, dual booting may be impossible then.
| Unless that firmware is downloaded every boot.
| garaetjjte wrote:
| Firmware is stored per-OS installation. (also DCP is
| unrelated to GPU)
| piinbinary wrote:
| What does a "discard if <condition>" instruction actually do?
| etaioinshrdlu wrote:
| It allows a pixel shader to basically return fully transparent,
| letting previously drawn objects show through.
| [deleted]
| GeekyBear wrote:
| According to Hector Martin in the last progress report, the Wifi
| driver is up next, then some not terribly demanding work on
| various drivers (like adapting the NetBSD driver for the real
| time clock, and getting the M1 iMac SKU with four USB ports to
| see all four) after which he will tackle the kernel driver for
| the GPU.
|
| https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
|
| As an interesting aside, in the progress report he mentions that
| after he installed Arch Linux, even without support for the
| hardware GPU:
|
| >glxgears has no right to run at >60FPS with software rendering,
| but it does
| Klinky wrote:
| When has glxgears ever been demanding[1]? I would hope a modern
| CPU could handle a few hundred vertices(guessing) at 60fps.
|
| 1.
| https://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmar...
___________________________________________________________________
(page generated 2021-12-18 23:00 UTC)