[RFC] Rename pmb:hw-accel to pmb:drm and deviceinfo_gpu_accelerated to deviceinfo_drm
Currently, we have two constructs related to GPU support: pmb:hw-accel for UI packages mandating GPU support, and deviceinfo_gpu_accelerated for devices with a working GPU. While this sounds nice in theory, it doesn't really match reality.
Most interfaces don't actually require 3D acceleration. They only require working DRM, which in some cases, e.g. on OMAP devices like espresso3g, comes without 3D acceleration. There's also SimpleDRM, which provides something similar to fbdev but compatible with DRM and works in more or less the same contexts as fbdev. However, it requires a recent kernel so it's a no-go for vendor kernels for now.
With the current classification system, devices like espresso3g can't have access to Phosh despite that it works just fine due to that it doesn't have GPU-accelerated 3D, even though this required by the Phosh shell. Marking it as GPU accelerated doesn't make sense since there is no working GPU acceleration. As such, I suggest that we rename pmb:hw-accel to pmb:drm and deviceinfo_gpu_accelerated to deviceinfo_drm to more accurately describe what these options do. Even this has some flaws, as DRM support is more of a scale than a yes or no kind of thing, but so is 3D acceleration — to an even greater extent — so I think this is fine. Thoughts?
Activity
added discussion label
mentioned in issue #1316 (closed)
By Newbyte on 2022-03-30T10:48:49
espresso3g can't have access to Phosh
I suggest espresso3g users that want to use phosh, do the following:
pmbootstrap config ui phosh pmbootstrap installBy Alexey Min on 2022-03-30T11:34:30
Edited by Administrator-
You mean, there sould be drm interfaces support without actuall 3d acceleration with things like simpledrm?
The reason some user interfaces don't work on "downstream"/Android vendor kernels is because they don't have working DRM, not because they don't have a working GPU. On mainline, SimpleDRM can provide DRM in situations where there's no working GPU (though in the case of espresso3g, OmapDRM is used).
By Newbyte on 2022-03-30T11:41:42
Edited by Administrator -
B-but.. as I said before users of espresso3g (for example) can still install with phosh if they like, even if it is not listed:
pmbootstrap config ui phosh. That is, if they want to suffer, of course, because yes - this will probably make possible to run shell, and some simple apps, but still laggy and barely usable. Which was the point of having these properties in the first place, to prevent users from having such experience.By Alexey Min on 2022-03-30T21:34:10
-
That is, if they want to suffer, of course, because yes - this will probably make possible to run shell, and some simple apps, but still laggy and barely usable. Which was the point of having these properties in the first place, to prevent users from having such experience.
Please look at the two videos I attached and tell me which one is using software rendering and which is using GPU rendering. Phosh shouldn't perform much different with LLVMpipe compared to a proper GPU. Some apps will very much perform better with a real GPU, but those apps are going to perform poorly in the list of UIs shown in pmbootstrap too.
By Newbyte on 2022-03-31T06:27:08
Edited by Administrator
-
Phosh is not the only shell that is marked as "requires HW accel". What about plaMo? can espresso3g run plaMo?
By Alexey Min on 2022-03-30T11:38:13
Edited by Administrator -
I would guess that performance wouldn't be great, but it should work. The option was originally introduced for the purpose of avoiding the situation where users end up with a black screen and go wtf it no work!!!!, and the current setup is not living up to this goal.
By Newbyte on 2022-03-30T11:38:13
-
why so? current setup worked fine so far
The original intention was to prevent users from installing UIs that would result in a black screen — which it does — but it doesn't take into consideration that you can have working DRM without a working GPU. As Android devices start using newer kernels that come with SimpleDRM, we should see downstream devices able to run Phosh and Plasma Mobile just fine with software rendering even though their GPUs don't work.
By Newbyte on 2022-03-30T12:12:01
-
-1, renaming deviceinfo properties will require too much, break backwards compatibility and you'll likely forget to do it in all places
By Alexey Min on 2022-03-30T11:39:06
Edited by Ghost User -
If you can find one example of deviceinfo being used outside of postmarketOS' own tooling, I can sympathise with the backwards compatibility point. I'm up for taking on the work necessary to make this change happen.
By Newbyte on 2022-03-30T11:39:26
Edited by Administrator -
We regularly make changes that require new releases of pmbootstrap. This property exists precisely for that reason: https://gitlab.postmarketos.org/postmarketos/pmaports/-/blob/master/pmaports.cfg#L4
By Newbyte on 2022-03-30T11:46:20
-
It's a change that would touch all device packages, making it one of the annoying commits to rebase around :(
By Martijn Braam on 2022-03-30T21:39:14
Edited by Ghost User -
It's a change that would touch all device packages, making it one of the annoying commits to rebase around :(
Sure, but that's a one-time thing.
By Newbyte on 2022-03-30T17:17:45
Edited by Ghost User
-
After reading craftyguy's comment here: !3041 (comment 892280348)
+1 to craftyguy, the original justification for the labelling was to prevent users from trying to run accelerated UIs like Phosh on devices which only have a framebuffer. I don't think this kind of documentation is something that the build system should be responsible for - we have wiki pages for this. UI options like sway have a huge
(DOES NOT RUN WITHOUT HW ACCELERATION!)as is.I think a sensible way to improve from that (as an alternative to the deviceinfo var) is to add a big bold messages above the UI list telling users to read the device wiki page to find out if GPU acceleration is supported and to check for any UI quirks specific to that device, this would include things like "we don't have GPU but we have a fast CPU and DRM, so you can use phosh if you don't mind it being slow". We then standardise how we denote in the list which UI's require DRM.
The "3D Acceleration" status does indicate DRM support in the vast majority of cases, devices that support DRM but don't have GPU acceleration can state this on their wiki page (under a section on "UI support" for example).
By Caleb Connolly on 2022-04-13T05:14:15
Edited by Ghost User -
espresso3g has a weak CPU and an 800p display. Can you tell which of the videos is using hardware-backed 3D acceleration and which is using software-backed 3D "acceleration"? I don't mean to sound like a jerk, but I don't believe that Phosh itself — as a shell — performs noticeably different without 3D acceleration. Yes, some apps will be slow, but they will be slow with Xfce4 too.
By Newbyte on 2022-04-13T05:46:29
Edited by Administrator -
well, I also stumbled about that option and wondering why sway seems to require hw accel. Especially in the case of ebook readers, things are even more crazy. Yes, everything supported by pmOS has drm. Some have Vivante GC320 2D GPU and GC355 Vector GPU. But you won't run anything with lots of animation there... As there is a standard API for refresh stuff, using drm instead of fbdev is an advantage.
By Andreas Kemnade on 2024-05-19T13:45:38
-
well, I also stumbled about that option and wondering why sway seems to require hw accel. Especially in the case of ebook readers, things are even more crazy. Yes, everything supported by pmOS has drm. Some have Vivante GC320 2D GPU and GC355 Vector GPU. But you won't run anything with lots of animation there... As there is a standard API for refresh stuff, using drm instead of fbdev is an advantage.
So, to clarify, you think Sway is useful on ebook readers despite them not having 3D acceleration?
By Newbyte on 2024-05-21T04:42:04
-
Basically I have thrown the EPD driver I have written myself against everything to test. Sway does not look like something gaining much from 3D acceleration. I did not use it intensively, I have not found out how to use it much without keyboard. But it does initially show something.
By Andreas Kemnade on 2024-05-22T18:35:31
Edited by Ghost User
-
Update: While I originally wrote the issue in good faith, it has come to light that both videos in the issue are running using software rendering via LLVMpipe as PowerVR had some issue with Phosh (I don't know the exact story). This was not known to neither me nor the person who recorded the videos (MightM17) at the time of writing, and I'm sorry that this was misleading, even if it was inadvertent. That said, I still stand by this change.
By Newbyte on 2022-05-05T13:06:27
-
My two cents:
-
in general, we can make changes to deviceinfo and rename variables etc. as it makes sense. It is some effort, but it's not unreasonable if there's a good reason for a change. Usually it would be:
- sed across pmaports.git to replace the variable
- backwards compatible code in pmbootstrap (we support multiple postmarketOS releases!) with a new "supported" variable in pmaports.cfg: https://wiki.postmarketos.org/wiki/Pmaports.cfg_reference
- check in pmbootstrap that the old variable isn't used anymore (we already do this for some variables; used in CI so we don't merge new devices with outdated vars)
-
for this change: I agree with what Clayton wrote/proposed in !3041 (comment 892280348):
This is an interesting suggestion! But I'm starting to think that maybe we shouldn't be trying to apply labels like this to the ui packages. pmb:drm might mean different things on different devices, from the user perspective... for instance on a device with a fast CPU, Phosh, GNOME, etc might be perfectly usable with SimpleDRM + sw rendering in Mesa. On another device with a slower CPU it might not be usable at all. With using something like pmb:drm, those UIs would show up for both devices in the example... I don't think it's helpful for pmbootstrap to offer unusable UIs for a device (which is why we have pmb:hw-accel in the first place.)
Perhaps what we should do instead is enable only lightweight UIs that work on any device ("weston", "none", "console", "xfce", things like that). Then maintain a list (in deviceinfo?) of UIs for each device where a human has tested it and determined that it performs reasonably well on the device to display as an option for pmbootstrap?
I think this would be the best experience for users, they get a list of UIs that are actually tested on the device instead of having to go by trail-and-error, or read more documentation to figure out what might work or not. I think maintaining a list of what UIs work or not in deviceinfo per device is reasonable effort; and for the devices that don't have such a list yet, we could display all UIs as fallback, mention that some may not work and ask users to send a patch that extends deviceinfo with information about which UIs work and which do not.
We could also let pmbootstrap display the known working list of UIs first, but add a command that will show all UIs in case the user wants to experiment and check if it's still broken or try to make it work there.
By Oliver Smith on 2022-05-06T07:35:40
-
-
Has anyone actually managed to get Phosh working with SimpleDRM? Last time I tried it, it didn't work (the error was something like
not able to load a backend).By Rayyan Ansari on 2022-06-14T23:33:31
Edited by Ghost User
mentioned in merge request !6419