Project

General

Profile

Actions

Issue #705

closed

Feature #1539: Graphics acceleration

Incomplete EGL implementation

Added by Paul Kocialkowski over 10 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
-
Category:
Graphics
Target version:
Start date:
11/12/2013
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed
Device:
Grant:
Type of work:

Description

Replicant is currently using the fallback Android EGL implementation, which is incomplete. The missing features of this implementation cause multiple issues:
  • Slowness issues on devices with slow CPUs
  • YUV is not properly supported (only black & white), which forces us to use RGB565 as a preview format on the camera modules. This causes several issues: * preview-based detection (such as barecodes, QR codes, etc) doesn't work * panorama feature is broken
  • Screenshots do not work
  • Previews of the windows in the tasks switcher are missing
  • Some applications rely on unimplemented features, such as Firefox, Document Viewer and crash as they are missing
There are patches to use llvmpipe with Replicant, and work is ongoing to:
  • investigate how to improve the performances of llvmpipe
  • investigate how to integrate llvmpipe and libagl at the same time on the device, in a clean way.
Actions #1

Updated by Rodger Fox over 10 years ago

Since slowness is the problem with Mesa, is this bug solvable in a way besides using graphics hardware?

Or should the focus be on contributing to and integrating projects like Lima driver into Replicant?

Actions #2

Updated by Paul Kocialkowski over 10 years ago

It would be possible to complete the Android EGL implementation so that it is fully-featured and optimize it with NEON and ARM ASM code so that it becomes faster. There are also ways to improve things with hwcomposer and the framebuffer drivers and other per-hardware things.

But the real way to solve this is to have per-GPU free software implementations, such as Lima. Lima is not ready yet, but once it doesn't depend on the proprietary compiler and gets integrated in mesa, we'll certainly try and make it work with Replicant.

Actions #3

Updated by My Self over 9 years ago

IMHO the Lima development stagnated since the last post, or are there any insider news?

I really want to take screenshots and the app alternative AndroSS:
https://f-droid.org/repository/browse/?fdfilter=screenshot&fdid=net.tedstein.AndroSS
doesn't work, too. (It takes screenshots, but the pictures are broken; looking like colored barcode art).

Does anybody knows a workaround for the screenshot feature (on Replicant), please?

Actions #4

Updated by Paul Kocialkowski over 9 years ago

IMHO the Lima development stagnated since the last post, or are there any insider news?

Quote: the tamil driver will see work whenever/ifever i am in the mood for working on it again

Does anybody knows a workaround for the screenshot feature (on Replicant), please?

Well, screenshots work on the browser, so maybe we should look how it's done there. I don't have time to work on graphics acceleration, as usual.

Actions #5

Updated by My Self over 9 years ago

[I've removed the system browser, so I can't test that].

But I've found a functional workaround to make screenshots over ADB:
http://blog.shvetsov.com/2013/02/grab-android-screenshot-to-computer-via.html

Actions #6

Updated by Paul Kocialkowski about 9 years ago

  • Target version changed from 21 to Any version
Actions #7

Updated by My Self about 9 years ago

IMHO the <incomplete EGL implementation> is an acute security related problem and will become a bigger one in the future.
The reason is, that I don't see another chance to get a more secure browser to work on Replicant without OpenGL ES, at the moment.
Please have a look at the discussion here: http://redmine.replicant.us/boards/39/topics/8007

A working EGL will bring also the following benefit:
  • There would be a workaround for "Add support for more video software-decoding codecs, such as Theora" from the Tasks list, because with a working Firefox, I've successfully tested to run a .ogv (Theora) Video file out of the browser.
  • This video was also switchable to fullscreen, so this could be another workaround for "Make the embedded video player in the browser work (or make it switch to fullscreen when playback starts)" on the Tasks list.
  • You could delete "Write a modern Gallery application that doesn't rely on missing OpenGL features" from the Tasks list.
  • Of course that would delete the EGL point itself "Improve the generic Android EGL implementation so that it implements all the currently missing features" from the Tasks list.
  • The points above could be the some kind of workaround for "Make software video decoding work on Replicant 4.2" on the Tasks list, too.
  • And last but not least, it (probably!) could lead to less battery consumption (http://redmine.replicant.us/boards/9/topics/7953) because there would be less (battery draining) software rendering, (but I have to test that first).
Actions #8

Updated by Denis 'GNUtoo' Carikli over 8 years ago

  • Parent task set to #1521
Actions #9

Updated by Denis 'GNUtoo' Carikli over 8 years ago

  • Parent task changed from #1521 to #1491
Actions #10

Updated by Denis 'GNUtoo' Carikli over 8 years ago

  • Parent task changed from #1491 to #1539
Actions #11

Updated by Denis 'GNUtoo' Carikli over 8 years ago

  • Device Not device specific added
Actions #12

Updated by Wolfgang Wiedmeyer about 7 years ago

  • Device added
  • Device deleted (Not device specific)
Actions #13

Updated by Wolfgang Wiedmeyer about 7 years ago

  • Category set to Graphics
  • Priority changed from High to Urgent
Actions #14

Updated by Wolfgang Wiedmeyer almost 7 years ago

  • Assignee deleted (Paul Kocialkowski)

llvmpipe is available in Replicant 6.0 and can optionally be enabled. It is still too slow to be the default renderer.

llvmpipe can become fast enough if it is optimized for ARM. Looking at optimized code for architectures that are supported by llvmpipe could be a viable strategy to figure out the instructions that are worth to optimize (e.g. by implementing them in ARM assembly).

Making use of ARM NEON should improve speed as well.

Actions #15

Updated by Wolfgang Wiedmeyer almost 7 years ago

  • Target version changed from Any version to Replicant 6.0
Actions #16

Updated by Wolfgang Wiedmeyer almost 7 years ago

llvmpipe in Replicant 6.0 is currently based on Mesa 13.0.3. We use the Mesa sources from Android-x86 and they updated to Mesa 17.0.4: https://osdn.net/projects/android-x86/scm/git/external-mesa/commits?branch=marshmallow-x86
Unfortunately, it's not possible to merge their updates because they seem to rebase. We only need one additional patch, so it's better to switch to a new branch and adapt our patch on top of it. This breaks the current way of how branches are handled. In other repos, there is only one branch per Replicant release. For the Mesa repo, we'd need several branches to preserve the tags.

Maybe a naming scheme for the branches like replicant-6.0-mesa-13.0, replicant-6.0-mesa-17.0 could work.

Actions #17

Updated by Niclas Hoyer over 6 years ago

Just a quick note: a new Mali-400 driver seems to be in very active development. It is far from complete, but passed a milestone on last week: it runs the kmscube successfully, so the whole stack basically works: https://github.com/yuq/mesa-lima/wiki

This GPU is used in Samsung i9100 and i9300, eventually others.

Actions #18

Updated by Denis 'GNUtoo' Carikli over 5 years ago

  • Description updated (diff)
Actions #19

Updated by Denis 'GNUtoo' Carikli about 5 years ago

Some time ago someone gave me that link on IRC: https://www.mesa3d.org/perf.html that explains how to increase performances in MESA when using software rendering.

Actions #20

Updated by Kurtis Hanna about 5 years ago

Niclas Hoyer posted a link a while ago to a new Mali-400 driver that still seems to be in very active development. They said that the whole stack basically worked back then, so I'd be curious to see how many bugs they still have left to fix. The link Niclas provided doesn't seem to be used anymore. You can find the links to the new active git repo here:

https://gitlab.freedesktop.org/lima
https://gitlab.freedesktop.org/lima/web/wikis/home

Actions #21

Updated by Kurtis Hanna over 4 years ago

It was reported that a Note 2 developer got the Lima driver running on 4.9 mainline kernel: https://github.com/CustomROMs/android_local_manifests_i9300/issues/1#issuecomment-524013455

An ODROID user got the lima driver running on 5.3-rc3 kernel: https://forum.odroid.com/viewtopic.php?f=55&t=3691&sid=f73a6ad3052ead98bb90fa7854d061db&start=400#p264856

Lima kernel driver is now loading with hacks on Replicant 9 using 5.3.0-rc5+ kernel https://github.com/CustomROMs/android_local_manifests_i9300/issues/1#issuecomment-524375690

Actions #22

Updated by Kurtis Hanna over 4 years ago

Here's a short video of Replicant 9 running Lima: http://www.belg.in/replicant_9.webm

Actions #23

Updated by Kurtis Hanna over 4 years ago

Should the target version for this issue be moved to Replicant 9?

Actions #24

Updated by dl lud over 4 years ago

No. It should be kept on Replicant 6. The patch for switching between libagl and llvmpipe fixes this for Replicant 6. (Although Firefox based browsers will still be slow.)

Actions #25

Updated by Denis 'GNUtoo' Carikli over 4 years ago

  • Target version changed from Replicant 6.0 to Replicant 6.0 0004

It should be fixed in the 0004 release

Actions #26

Updated by Kurtis Hanna about 4 years ago

  • Status changed from New to Resolved
  • Resolution set to fixed

Since dllud said, "The patch for switching between libagl and llvmpipe fixes this for Replicant 6" and since that patch was pushed https://lists.osuosl.org/pipermail/replicant/2019-December/002371.html I'm closing this issue.

Please feel free to open it back up if I'm mistaken here.

Actions

Also available in: Atom PDF