> The current submission can power up the GPU and probe the device on an RK3588 system-on-chip. This lets us read a few sections of ROM in the GPU, which in turn lets us provide this information to userspace by means of a DRM_IOCTL_PANTHOR_DEV_QUERY call.
I think ARM-based chips and embedded GPUs continue to be problematic. Powering up a GPU is not the issue, it's accessing the silicon that does specialised accelerated functionality without getting tied into some crazy legal stuff with the documentation required to do so. Reverse engineering your way to a working GPU driver is quite an effort.
I think I first came across this issue in the PineTab [1]. I was trying to do some kind of streaming from the device but it was ultra slow. After some search I found that Sunxi [2] was the only real serious effort at the time, and that it was sporting a Mali400 [3] [4]. ARM were not particularly friendly in open sourcing GPU code for the kernel and it was largely a reverse engineering effort that got anything working at all [5].
All this to say, I would rather support some kind of open-source GPU effort [6], especially if it could be boiled down to a small SoC or module. I saw this crazy 160 core RISC-V M.2 cluster performing ray tracing, and it really seems like we could get there [7].
Direct Rendering Manager (DRM) has to be one of the worst possible re-uses of an acronym ever. This is the second time I've seen it used recently without an expansion of the acronym.
The GPUs themselves are named after norse mythology (utgard, midgard, bifrost, valhall), the driver names have been related to those (panfrost, panthor, and now tyr). And the whole theme comes from the fact that the GPUs originate from Norwegian company (later acquired by ARM)
In case anyone is confused, DRM refers to Direct Rendering Manager, not Digital Rights Management: https://en.wikipedia.org/wiki/Direct_Rendering_Manager
That acronym has always bothered me. Why use DRM when there's already perfectly good alternatives like "GPU" or "graphics".
Like take this:
> substantial progress on the DRM infrastructure required to write GPU drivers
It's basically saying
> substantial progress on the GPU driver infrastructure required to write GPU drivers
The headline could just be "Tyr, a new Rust CSF-based ARM Mali GPU driver" which is both shorter and avoids the DRM confusion.
Thanks, that's exactly what was confusing me.
Yeah that would be not a very proud thing to share
> The current submission can power up the GPU and probe the device on an RK3588 system-on-chip. This lets us read a few sections of ROM in the GPU, which in turn lets us provide this information to userspace by means of a DRM_IOCTL_PANTHOR_DEV_QUERY call.
I think ARM-based chips and embedded GPUs continue to be problematic. Powering up a GPU is not the issue, it's accessing the silicon that does specialised accelerated functionality without getting tied into some crazy legal stuff with the documentation required to do so. Reverse engineering your way to a working GPU driver is quite an effort.
I think I first came across this issue in the PineTab [1]. I was trying to do some kind of streaming from the device but it was ultra slow. After some search I found that Sunxi [2] was the only real serious effort at the time, and that it was sporting a Mali400 [3] [4]. ARM were not particularly friendly in open sourcing GPU code for the kernel and it was largely a reverse engineering effort that got anything working at all [5].
All this to say, I would rather support some kind of open-source GPU effort [6], especially if it could be boiled down to a small SoC or module. I saw this crazy 160 core RISC-V M.2 cluster performing ray tracing, and it really seems like we could get there [7].
[1] https://wiki.pine64.org/wiki/PineTab
[2] https://linux-sunxi.org/Allwinner_SoC_Family
[3] https://linux-sunxi.org/A64
[4] https://linux-sunxi.org/Mali
[5] https://en.wikipedia.org/wiki/Free_and_open-source_graphics_...
[6] https://www.tomshardware.com/pc-components/gpus/new-open-sou...
[7] https://www.youtube.com/watch?v=HRfbQJ6FdF0
Direct Rendering Manager (DRM) has to be one of the worst possible re-uses of an acronym ever. This is the second time I've seen it used recently without an expansion of the acronym.
Both of them, "Digital Rights Management" as a term and the Direct Rendering Manager, are about the same age.
The legal term for it, from the DMCA, "Technological Protection Measures", also conflicts with another acronym :)
Direct Rendering Manager doesn't predate the concept of digital rights management, but it might predate the widespread usage of the acronym.
From I remember, back int the 90's, "copy protection", was the common term in use.
One thing that wasn't mentioned, what was the motivation for the re-write?
[flagged]
The GPUs themselves are named after norse mythology (utgard, midgard, bifrost, valhall), the driver names have been related to those (panfrost, panthor, and now tyr). And the whole theme comes from the fact that the GPUs originate from Norwegian company (later acquired by ARM)
https://en.wikipedia.org/wiki/Mali_(processor)
[flagged]