Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2020-01-02 Thread Denis 'GNUtoo' Carikli
On Mon, 23 Dec 2019 21:36:39 +0100
Denis 'GNUtoo' Carikli  wrote:

> According to Adfeno on IRC, that patch is supposed to make the stock
> graphical interface about as fast than it was before.
> 
> With libagl being switched to "ro.libagl=0" with the scripts to do
> that, the graphical interface is way slower.
> 
> Do you have any clue of what could be going wrong.
The issue I had was related to the fact that I had an old data/ being
carried around since a lot of time.

With a new data/ it's now fast.

I'll a new version patches for the 2 changes mentioned in this thread.

There is not much being changed since last time beside improvements in
the commit messages, so it should be fast to review.

Denis.


pgpw45asKGNkP.pgp
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-12-23 Thread Denis 'GNUtoo' Carikli
On Thu, 12 Dec 2019 23:52:20 +
dllud  wrote:

> Thanks a lot for preparing the patch Denis.
> 
> It is missing one important thing though. Please set "ro.libagl=0" in
> vendor/replicant/config/common.mk line 242. Like this:
> 
[...]
> Particularly, this patch places some files that make bootanimation,
> SurfaceFlinger and system_server use libagl instead of the default
> (llvmpipe).
> That's required because these 3 components are too slow with llvmpipe.
According to Adfeno on IRC, that patch is supposed to make the stock
graphical interface about as fast than it was before.

With libagl being switched to "ro.libagl=0" with the scripts to do
that, the graphical interface is way slower.

Do you have any clue of what could be going wrong.

As far as I know, this is the last serie of patches we need to merge
before building release candidate images (and potentially finding bugs
that forces us to make some more patches/fixes).

Denis.


pgpzGb_Kg_2v1.pgp
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-12-12 Thread dllud
Thanks a lot for preparing the patch Denis.

It is missing one important thing though. Please set "ro.libagl=0" in
vendor/replicant/config/common.mk line 242. Like this:

- # use Android's software renderer by default
- PRODUCT_PROPERTY_OVERRIDES += ro.libagl=1
+ # This makes sure that Mesa (llvmpipe) is used as the default renderer
+ PRODUCT_PROPERTY_OVERRIDES += ro.libagl=0

Unto how the patch works. Setting ro.libagl=0 has above makes sure that
frameworks/native/tree/opengl/libs/EGL/Loader.cpp selects
/system/lib/egl/libGLES_mesa.so (llvmpipe) as the default renderer
(behaviour is on the class "MatchFile").

This default renderer can then be overwritten on a per-app basis by
placing empty files in specific directories. That's what the previous
Andrés' patches (that were merged) allow us to do. The specific
directories and the workings of it are explained by Andrés in the first
email of this patch series:
https://lists.osuosl.org/pipermail/replicant/2019-August/002054.html

Particularly, this patch places some files that make bootanimation,
SurfaceFlinger and system_server use libagl instead of the default
(llvmpipe).
That's required because these 3 components are too slow with llvmpipe.

Right now I am unable to produce a Replicant 6 build, but I have a spare
i9300 where I can test. Could you please create a build including a
fixed version of this patch (as per above) and upload it somewhere? I'll
flash it and let you know if it is as fast as it should be.

On 12/12/2019 23:01, Denis 'GNUtoo' Carikli wrote:
> On Thu, 12 Dec 2019 02:35:34 +
> dllud  wrote:
> 
>> Sorry, my bad, as Joonas correctly reviewed, the last patch shouldn't
>> be merged.
>> Instead, "ro.libagl=0" should be set in
>> vendor/replicant/config/common.mk in order to have llvmpipe as
>> default. 
> Thanks. During testing, I was wondering why it wasn't set, now I
> get it.
> 
>> Along with that we need the two commits from adjtm that I
>> mentioned previously, otherwise the system will be too slow.
> I've prepared a patch with that but while it may look good it's nowhere
> ready:
> - I need the permission to add signed-off-by from Andrés Domínguez
> - The commit message reflects what it's supposed to do but I've no idea
>   how it's supposed to work. All I see is that it copies some empty
>   files in some specific locations.
> - As I don't understand how it works, I don't understand either how to
>   test it.
> 
> As I've added the llvmpipe.sh and androidsw.sh scripts to the image, I
> just had to run llvmpipe.sh to enable llvmpipe. Once that was done, I
> found the "desktop/launcher" way slower than with ro.libagl=1.
> 
> Beside that I'm not sure how fast it's supposed to be.
> 
> Denis.
> 



signature.asc
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-12-12 Thread Denis 'GNUtoo' Carikli
On Thu, 12 Dec 2019 02:35:34 +
dllud  wrote:

> Sorry, my bad, as Joonas correctly reviewed, the last patch shouldn't
> be merged.
> Instead, "ro.libagl=0" should be set in
> vendor/replicant/config/common.mk in order to have llvmpipe as
> default. 
Thanks. During testing, I was wondering why it wasn't set, now I
get it.

> Along with that we need the two commits from adjtm that I
> mentioned previously, otherwise the system will be too slow.
I've prepared a patch with that but while it may look good it's nowhere
ready:
- I need the permission to add signed-off-by from Andrés Domínguez
- The commit message reflects what it's supposed to do but I've no idea
  how it's supposed to work. All I see is that it copies some empty
  files in some specific locations.
- As I don't understand how it works, I don't understand either how to
  test it.

As I've added the llvmpipe.sh and androidsw.sh scripts to the image, I
just had to run llvmpipe.sh to enable llvmpipe. Once that was done, I
found the "desktop/launcher" way slower than with ro.libagl=1.

Beside that I'm not sure how fast it's supposed to be.

Denis.
From 89f79f3677250acfb0bcd1fe5245265fbbe438ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9s=20Dom=C3=ADnguez?= 
Date: Tue, 9 Apr 2019 15:39:56 +
Subject: [PATCH] [WIP] Add configuration files for default libGLES overlays

Libagl was previously used for all applications. That
prevented to use applications like IceCatMobile, which were
crashing because libagl OpenGL implementation was
incomplete.

To fix that, LLVMpipe is now used by default, however this
creates some huge performance issues for the following
system components:
- bootanimation
- SurfaceFlinger
- system_server

As theses system components are known to work well with
libagl, and that having different OpenGL implementations
doesn't seem to create any issue, it's safe to switch them
back to libagl.

gnu...@cyberdimension.org: squashed commits, commit message: added background
Signed-off-by: Denis 'GNUtoo' Carikli 
---
 config/common.mk  | 4 
 prebuilt/common/etc/libGLES_android/system/bin/bootanimation  | 0
 prebuilt/common/etc/libGLES_android/system/bin/surfaceflinger | 0
 prebuilt/common/etc/libGLES_android/system_server | 0
 4 files changed, 4 insertions(+)
 create mode 100644 prebuilt/common/etc/libGLES_android/system/bin/bootanimation
 create mode 100644 prebuilt/common/etc/libGLES_android/system/bin/surfaceflinger
 create mode 100644 prebuilt/common/etc/libGLES_android/system_server

diff --git a/config/common.mk b/config/common.mk
index a79025f6..8d7d841d 100644
--- a/config/common.mk
+++ b/config/common.mk
@@ -90,6 +90,10 @@ PRODUCT_COPY_FILES += \
 PRODUCT_COPY_FILES += \
 vendor/replicant/prebuilt/common/etc/firmware/htc_9271.fw:system/etc/firmware/htc_9271.fw
 
+# Copy default EGL overrides
+PRODUCT_COPY_FILES += \
+$(call find-copy-subdir-files,*,vendor/replicant/prebuilt/common/etc/libGLES_android,system/etc/libGLES_android)
+
 # Include CM audio files
 include vendor/replicant/config/cm_audio.mk
 
diff --git a/prebuilt/common/etc/libGLES_android/system/bin/bootanimation b/prebuilt/common/etc/libGLES_android/system/bin/bootanimation
new file mode 100644
index ..e69de29b
diff --git a/prebuilt/common/etc/libGLES_android/system/bin/surfaceflinger b/prebuilt/common/etc/libGLES_android/system/bin/surfaceflinger
new file mode 100644
index ..e69de29b
diff --git a/prebuilt/common/etc/libGLES_android/system_server b/prebuilt/common/etc/libGLES_android/system_server
new file mode 100644
index ..e69de29b
-- 
2.24.0



pgpmUJ3f80m8J.pgp
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-12-11 Thread dllud
Sorry, my bad, as Joonas correctly reviewed, the last patch shouldn't be
merged.
Instead, "ro.libagl=0" should be set in
vendor/replicant/config/common.mk in order to have llvmpipe as default.
Along with that we need the two commits from adjtm that I mentioned
previously, otherwise the system will be too slow.

On 11/12/2019 15:43, dllud wrote:
> The last patch (PATCH 7/7) should be pushed alongside with a new patch
> that includes the content of the following two commits available on
> adjtm's personal repo:
> https://github.com/andresdju/vendor_replicant/commit/19fe4dddff99ba0a12b4ff2545df65562170847b
> https://github.com/andresdju/vendor_replicant/commit/bd2bb9899f5ea117669912457c0fdead1bef9166
> 
> This will bring in the sane defaults that adjtm's experimental builds
> include: llvmpipe used everywhere except SurfaceFlinger.
> I've been using this configuration as my daily driver for 6 months now
> and it works rather well. llvmpipe is comparable in terms of performance
> to libagl in pretty much every app. I felt no need to revert any app
> back to libagl.
> Having llvmpipe as default makes sure that Firefox based browsers work
> out-of-the-box, with no need for the user to mess with the graphics config.
> 
> adjtm, could you please send in a patch that includes the result of
> those two commits?
> 



signature.asc
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-12-11 Thread dllud
The last patch (PATCH 7/7) should be pushed alongside with a new patch
that includes the content of the following two commits available on
adjtm's personal repo:
https://github.com/andresdju/vendor_replicant/commit/19fe4dddff99ba0a12b4ff2545df65562170847b
https://github.com/andresdju/vendor_replicant/commit/bd2bb9899f5ea117669912457c0fdead1bef9166

This will bring in the sane defaults that adjtm's experimental builds
include: llvmpipe used everywhere except SurfaceFlinger.
I've been using this configuration as my daily driver for 6 months now
and it works rather well. llvmpipe is comparable in terms of performance
to libagl in pretty much every app. I felt no need to revert any app
back to libagl.
Having llvmpipe as default makes sure that Firefox based browsers work
out-of-the-box, with no need for the user to mess with the graphics config.

adjtm, could you please send in a patch that includes the result of
those two commits?



signature.asc
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-10-14 Thread Joonas Kylmälä
Hi,

pushed all except the last patch.

Joonas Kylmälä:
> Hi,
> 
> thanks for the reply!
> 
> I'm planning to push these patches tomorrow so if you have any
> objections please do that now.
> 
> Joonas
> 
> Andrés Domínguez:
>> Hi.
>>
>> As Joonas says, that last patch should not be pushed, without it we have
>> the expected behavior: it uses the system default opengles renderer.
>>
>> Andrés Domínguez
>>
>> El jue., 10 oct. 2019 a las 20:07, Joonas Kylmälä ()
>> escribió:
>>
>>> Hi,
>>>
>>> so we didn't get anyone to review these patches except the last one:
>>> . The last patch
>>> turned out to be not needed as my testing showed and reading the patch's
>>> logic it is doing nothing except forcing llvmpipe which is not wanted. I
>>> suggest we push these patches except the last one now even if there is
>>> no review as more than one week has passed.
>>>
>>> I'm still hoping to hear from at least some of you in the To field of
>>> this email whether you are okay pushing the patches.
>>>
>>> Joonas
>>>
>>> Joonas Kylmälä:
 Hi,

 I got this setup working successfully if I don't apply the last patch.
 Without the last patch I can choose the default renderer with
 instructions at

>>> https://redmine.replicant.us/projects/replicant/wiki/Graphics#Enabling-llvmpipe-as-software-renderer
>>> .

 And then if the system default renderer is llvmpipe and I want browser
 to work with libagl I run: mkdir /etc/libGLES_android && touch
 /etc/libGLES_android/com.android.browser.

 And if the system default renderer is libagl and I want browser to work
 with llvmpipe I run: mkdir /etc/libGLES_mesa/ && touch
 /etc/libGLES_mesa/com.android.browser

 Without the last patch:

 Tested-by: Joonas Kylmälä 

 Joonas

 Andrés Domínguez:
> Selection of libagl or llvmpipe at EGL link time. It's based
> on the work of Jookia and JeremyRand, but it uses files for
> configuration instead of properties or symlinks.
>
>
> First it looks for files with the names libGLES_mesa and
> libGLES_android (in this order) inside
> /data/data//, it links to the first it finds.
> Then it looks for a file with process name inside
> /system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
> (again in this order). This is useful for processes that
> don't have app folder in the data partition, like
> surfaceflinger, system-server or bootanimation.
> Surfaceflinger should definitely use libagl, because it's
> extremely slow with llvmpipe.
>
> The solution is not elegant but it's simple and I don't
> except this to be used in Replicant 9 or latter.
>
> Andrés Domínguez
>
>
> Andrés Domínguez (2):
>   Change symlinks to files and static paths
>   Allow overrides of zygote's libGLES preload. Default to mesa
>
> JeremyRand (5):
>   EGL Loader patch to use both LLVMpipe and libagl at once
>   EGL renderer override: use symlinks instead of properties to specify
> overrides.
>   Fix some type fails in EGL renderer override
>   Fix documentation typo in EGL renderer override
>   Fix checking of access() return value in EGL renderer override
>
>  opengl/libs/EGL/Loader.cpp | 140 ++---
>  1 file changed, 114 insertions(+), 26 deletions(-)
>
 ___
 Replicant mailing list
 Replicant@osuosl.org
 https://lists.osuosl.org/mailman/listinfo/replicant

>>>
>>
> ___
> Replicant mailing list
> Replicant@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/replicant
> 
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-10-13 Thread Joonas Kylmälä
Hi,

thanks for the reply!

I'm planning to push these patches tomorrow so if you have any
objections please do that now.

Joonas

Andrés Domínguez:
> Hi.
> 
> As Joonas says, that last patch should not be pushed, without it we have
> the expected behavior: it uses the system default opengles renderer.
> 
> Andrés Domínguez
> 
> El jue., 10 oct. 2019 a las 20:07, Joonas Kylmälä ()
> escribió:
> 
>> Hi,
>>
>> so we didn't get anyone to review these patches except the last one:
>> . The last patch
>> turned out to be not needed as my testing showed and reading the patch's
>> logic it is doing nothing except forcing llvmpipe which is not wanted. I
>> suggest we push these patches except the last one now even if there is
>> no review as more than one week has passed.
>>
>> I'm still hoping to hear from at least some of you in the To field of
>> this email whether you are okay pushing the patches.
>>
>> Joonas
>>
>> Joonas Kylmälä:
>>> Hi,
>>>
>>> I got this setup working successfully if I don't apply the last patch.
>>> Without the last patch I can choose the default renderer with
>>> instructions at
>>>
>> https://redmine.replicant.us/projects/replicant/wiki/Graphics#Enabling-llvmpipe-as-software-renderer
>> .
>>>
>>> And then if the system default renderer is llvmpipe and I want browser
>>> to work with libagl I run: mkdir /etc/libGLES_android && touch
>>> /etc/libGLES_android/com.android.browser.
>>>
>>> And if the system default renderer is libagl and I want browser to work
>>> with llvmpipe I run: mkdir /etc/libGLES_mesa/ && touch
>>> /etc/libGLES_mesa/com.android.browser
>>>
>>> Without the last patch:
>>>
>>> Tested-by: Joonas Kylmälä 
>>>
>>> Joonas
>>>
>>> Andrés Domínguez:
 Selection of libagl or llvmpipe at EGL link time. It's based
 on the work of Jookia and JeremyRand, but it uses files for
 configuration instead of properties or symlinks.


 First it looks for files with the names libGLES_mesa and
 libGLES_android (in this order) inside
 /data/data//, it links to the first it finds.
 Then it looks for a file with process name inside
 /system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
 (again in this order). This is useful for processes that
 don't have app folder in the data partition, like
 surfaceflinger, system-server or bootanimation.
 Surfaceflinger should definitely use libagl, because it's
 extremely slow with llvmpipe.

 The solution is not elegant but it's simple and I don't
 except this to be used in Replicant 9 or latter.

 Andrés Domínguez


 Andrés Domínguez (2):
   Change symlinks to files and static paths
   Allow overrides of zygote's libGLES preload. Default to mesa

 JeremyRand (5):
   EGL Loader patch to use both LLVMpipe and libagl at once
   EGL renderer override: use symlinks instead of properties to specify
 overrides.
   Fix some type fails in EGL renderer override
   Fix documentation typo in EGL renderer override
   Fix checking of access() return value in EGL renderer override

  opengl/libs/EGL/Loader.cpp | 140 ++---
  1 file changed, 114 insertions(+), 26 deletions(-)

>>> ___
>>> Replicant mailing list
>>> Replicant@osuosl.org
>>> https://lists.osuosl.org/mailman/listinfo/replicant
>>>
>>
> 
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-10-13 Thread Andrés Domínguez
Hi.

As Joonas says, that last patch should not be pushed, without it we have
the expected behavior: it uses the system default opengles renderer.

Andrés Domínguez

El jue., 10 oct. 2019 a las 20:07, Joonas Kylmälä ()
escribió:

> Hi,
>
> so we didn't get anyone to review these patches except the last one:
> . The last patch
> turned out to be not needed as my testing showed and reading the patch's
> logic it is doing nothing except forcing llvmpipe which is not wanted. I
> suggest we push these patches except the last one now even if there is
> no review as more than one week has passed.
>
> I'm still hoping to hear from at least some of you in the To field of
> this email whether you are okay pushing the patches.
>
> Joonas
>
> Joonas Kylmälä:
> > Hi,
> >
> > I got this setup working successfully if I don't apply the last patch.
> > Without the last patch I can choose the default renderer with
> > instructions at
> >
> https://redmine.replicant.us/projects/replicant/wiki/Graphics#Enabling-llvmpipe-as-software-renderer
> .
> >
> > And then if the system default renderer is llvmpipe and I want browser
> > to work with libagl I run: mkdir /etc/libGLES_android && touch
> > /etc/libGLES_android/com.android.browser.
> >
> > And if the system default renderer is libagl and I want browser to work
> > with llvmpipe I run: mkdir /etc/libGLES_mesa/ && touch
> > /etc/libGLES_mesa/com.android.browser
> >
> > Without the last patch:
> >
> > Tested-by: Joonas Kylmälä 
> >
> > Joonas
> >
> > Andrés Domínguez:
> >> Selection of libagl or llvmpipe at EGL link time. It's based
> >> on the work of Jookia and JeremyRand, but it uses files for
> >> configuration instead of properties or symlinks.
> >>
> >>
> >> First it looks for files with the names libGLES_mesa and
> >> libGLES_android (in this order) inside
> >> /data/data//, it links to the first it finds.
> >> Then it looks for a file with process name inside
> >> /system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
> >> (again in this order). This is useful for processes that
> >> don't have app folder in the data partition, like
> >> surfaceflinger, system-server or bootanimation.
> >> Surfaceflinger should definitely use libagl, because it's
> >> extremely slow with llvmpipe.
> >>
> >> The solution is not elegant but it's simple and I don't
> >> except this to be used in Replicant 9 or latter.
> >>
> >> Andrés Domínguez
> >>
> >>
> >> Andrés Domínguez (2):
> >>   Change symlinks to files and static paths
> >>   Allow overrides of zygote's libGLES preload. Default to mesa
> >>
> >> JeremyRand (5):
> >>   EGL Loader patch to use both LLVMpipe and libagl at once
> >>   EGL renderer override: use symlinks instead of properties to specify
> >> overrides.
> >>   Fix some type fails in EGL renderer override
> >>   Fix documentation typo in EGL renderer override
> >>   Fix checking of access() return value in EGL renderer override
> >>
> >>  opengl/libs/EGL/Loader.cpp | 140 ++---
> >>  1 file changed, 114 insertions(+), 26 deletions(-)
> >>
> > ___
> > Replicant mailing list
> > Replicant@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/replicant
> >
>
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-10-10 Thread Joonas Kylmälä
Hi,

so we didn't get anyone to review these patches except the last one:
. The last patch
turned out to be not needed as my testing showed and reading the patch's
logic it is doing nothing except forcing llvmpipe which is not wanted. I
suggest we push these patches except the last one now even if there is
no review as more than one week has passed.

I'm still hoping to hear from at least some of you in the To field of
this email whether you are okay pushing the patches.

Joonas

Joonas Kylmälä:
> Hi,
> 
> I got this setup working successfully if I don't apply the last patch.
> Without the last patch I can choose the default renderer with
> instructions at
> https://redmine.replicant.us/projects/replicant/wiki/Graphics#Enabling-llvmpipe-as-software-renderer.
> 
> And then if the system default renderer is llvmpipe and I want browser
> to work with libagl I run: mkdir /etc/libGLES_android && touch
> /etc/libGLES_android/com.android.browser.
> 
> And if the system default renderer is libagl and I want browser to work
> with llvmpipe I run: mkdir /etc/libGLES_mesa/ && touch
> /etc/libGLES_mesa/com.android.browser
> 
> Without the last patch:
> 
> Tested-by: Joonas Kylmälä 
> 
> Joonas
> 
> Andrés Domínguez:
>> Selection of libagl or llvmpipe at EGL link time. It's based
>> on the work of Jookia and JeremyRand, but it uses files for
>> configuration instead of properties or symlinks.
>>
>>
>> First it looks for files with the names libGLES_mesa and
>> libGLES_android (in this order) inside
>> /data/data//, it links to the first it finds.
>> Then it looks for a file with process name inside
>> /system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
>> (again in this order). This is useful for processes that
>> don't have app folder in the data partition, like
>> surfaceflinger, system-server or bootanimation.
>> Surfaceflinger should definitely use libagl, because it's
>> extremely slow with llvmpipe.
>>
>> The solution is not elegant but it's simple and I don't
>> except this to be used in Replicant 9 or latter.
>>
>> Andrés Domínguez
>>
>>
>> Andrés Domínguez (2):
>>   Change symlinks to files and static paths
>>   Allow overrides of zygote's libGLES preload. Default to mesa
>>
>> JeremyRand (5):
>>   EGL Loader patch to use both LLVMpipe and libagl at once
>>   EGL renderer override: use symlinks instead of properties to specify
>> overrides.
>>   Fix some type fails in EGL renderer override
>>   Fix documentation typo in EGL renderer override
>>   Fix checking of access() return value in EGL renderer override
>>
>>  opengl/libs/EGL/Loader.cpp | 140 ++---
>>  1 file changed, 114 insertions(+), 26 deletions(-)
>>
> ___
> Replicant mailing list
> Replicant@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/replicant
> 
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-10-09 Thread Joonas Kylmälä
Hi,

I got this setup working successfully if I don't apply the last patch.
Without the last patch I can choose the default renderer with
instructions at
https://redmine.replicant.us/projects/replicant/wiki/Graphics#Enabling-llvmpipe-as-software-renderer.

And then if the system default renderer is llvmpipe and I want browser
to work with libagl I run: mkdir /etc/libGLES_android && touch
/etc/libGLES_android/com.android.browser.

And if the system default renderer is libagl and I want browser to work
with llvmpipe I run: mkdir /etc/libGLES_mesa/ && touch
/etc/libGLES_mesa/com.android.browser

Without the last patch:

Tested-by: Joonas Kylmälä 

Joonas

Andrés Domínguez:
> Selection of libagl or llvmpipe at EGL link time. It's based
> on the work of Jookia and JeremyRand, but it uses files for
> configuration instead of properties or symlinks.
> 
> 
> First it looks for files with the names libGLES_mesa and
> libGLES_android (in this order) inside
> /data/data//, it links to the first it finds.
> Then it looks for a file with process name inside
> /system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
> (again in this order). This is useful for processes that
> don't have app folder in the data partition, like
> surfaceflinger, system-server or bootanimation.
> Surfaceflinger should definitely use libagl, because it's
> extremely slow with llvmpipe.
> 
> The solution is not elegant but it's simple and I don't
> except this to be used in Replicant 9 or latter.
> 
> Andrés Domínguez
> 
> 
> Andrés Domínguez (2):
>   Change symlinks to files and static paths
>   Allow overrides of zygote's libGLES preload. Default to mesa
> 
> JeremyRand (5):
>   EGL Loader patch to use both LLVMpipe and libagl at once
>   EGL renderer override: use symlinks instead of properties to specify
> overrides.
>   Fix some type fails in EGL renderer override
>   Fix documentation typo in EGL renderer override
>   Fix checking of access() return value in EGL renderer override
> 
>  opengl/libs/EGL/Loader.cpp | 140 ++---
>  1 file changed, 114 insertions(+), 26 deletions(-)
> 
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


Re: [Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-09-06 Thread Denis 'GNUtoo' Carikli
On Thu, 15 Aug 2019 21:04:26 +0200
Andrés Domínguez  wrote:

> Selection of libagl or llvmpipe at EGL link time. It's based
> on the work of Jookia and JeremyRand, but it uses files for
> configuration instead of properties or symlinks.
Hi,

I tried to review the patches but I lack enough knowledge on the
graphics stack to understand what they do.

It would be great if someone else than me is able to review the patches.

Else me and/or other people could still try to test them, and if they
work and don't break anything, we could still merge them without the
Acked-by as more than one week has passed now.

Denis.


pgpJwYssYi_QT.pgp
Description: OpenPGP digital signature
___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant


[Replicant] [PATCH 0/7] Per process libagl/llvmpipe

2019-08-15 Thread Andrés Domínguez
Selection of libagl or llvmpipe at EGL link time. It's based
on the work of Jookia and JeremyRand, but it uses files for
configuration instead of properties or symlinks.


First it looks for files with the names libGLES_mesa and
libGLES_android (in this order) inside
/data/data//, it links to the first it finds.
Then it looks for a file with process name inside
/system/etc/libGLES_mesa/ and /system/etc/libGLES_android/
(again in this order). This is useful for processes that
don't have app folder in the data partition, like
surfaceflinger, system-server or bootanimation.
Surfaceflinger should definitely use libagl, because it's
extremely slow with llvmpipe.

The solution is not elegant but it's simple and I don't
except this to be used in Replicant 9 or latter.

Andrés Domínguez


Andrés Domínguez (2):
  Change symlinks to files and static paths
  Allow overrides of zygote's libGLES preload. Default to mesa

JeremyRand (5):
  EGL Loader patch to use both LLVMpipe and libagl at once
  EGL renderer override: use symlinks instead of properties to specify
overrides.
  Fix some type fails in EGL renderer override
  Fix documentation typo in EGL renderer override
  Fix checking of access() return value in EGL renderer override

 opengl/libs/EGL/Loader.cpp | 140 ++---
 1 file changed, 114 insertions(+), 26 deletions(-)

-- 
2.23.0.rc1

___
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant