Beta testing campaign for new vulkan enabled oreo-x86 ISOs

[Mauro Rossi]

Hi to all community members and interested people,

thanks to effort and contribution of lambdadroid drm_framebuffer as a complement to gbm_gralloc,

it is possible to enable the available vulkan HALs w/o using drm_hwcomposer.

This allows to use gralloc.gbm module (gbm_gralloc + static drm_framebuffer library) 

as a proficient replacement for gralloc.drm for intel drivers, radeon drivers , amdgpu

thus enabling anv and radv vulkan HALs as those were incompatible with gralloc.drm

ISO images are being uploaded here:

https://drive.google.com/drive/u/1/folders/1Z5H_DUPYaSqlpBV0HVWz8XfOlcQqMVYS

oreo 8.1 kernel 4.19 & mesa 18.3.x ISOs (please concentrate your Beta testing efforts here)

There was an issue causing  many 32bit  apps crash in 64 bit builds caused by the gralloc_handle.h handle structure, 

now used by gbm_gralloc, due to missing porting of Chih-Wei patch in libdrm's android/gralloc_handle.h

now the problem is solved and vulkan HALs anv and radv are working quite well.

There are still some issues:

1. Missing implementation of Screen Mirroring to External Connector for feature parity with drm_gralloc

2. vmwgfx no GUI - now it can be debugged using virtualbox 6.0 beta with new VMSVGA driver for acceleration - some people were interested

3. nouveau/i915 "google stopped" at create bitmap from render node - there is a common root cause to this problem

4. ResolverActivity glitches due to sw read/write often

5. Nouveau GPU lockup at sign-in or occasional sporadic nouveau GPU lockup after installation and sign-in done on another GPU

6. Printscreen snapshot not working

7. Some graphic glitches in Chicken Invaders 3

8. Some issues with native bridge in 32bit build affecting few applications e.g. Olympus Rising in 32bit ISO.

We need support from both skilled developers to try to tackle with 1, 2, 3, 4, 5, 6, as opposed to being completely alone in this,

and hobby testers to verify and report graphical issues on apps/games and providing logs/tombstones.

Evergreen, GCN 2nd gen to RX560 Polaris have been tested, APU, Ryzen, Vega may require some further verifications/confirmations.

The goals are:

- to verify on latest GPU parts with Vulkan apps (Vulkan V1, 3Dmark)

- to speed-up problems resolution by also releasing the recipe scripts (in the attachments)

Please provide your test, issues report in this thread and, hopefully, some patches to solve part of the issues!

Mauro

PS: for people who may ask about nougat-x86 with updated drivers, this is not the purpose of this thread, 

you can use the oreo-x86 branches and this patch [p] if you want to update Android 7.1.2, but you are on your own.

[p] http://git.osdn.net/view?p=android-x86/art.git;a=commit;h=edb557db300d6632fa6d62f5695cfa9eca6bcbdf

[Michael Goffioul]

HI Mauro,

I've tried this image on my platform: oreo_x86_8.1.0_r48_drm_fb_k419_llvm70_mesa-18.3.0_radv_vulkan_1.1.70.iso

Baytrail with Intel Celeron N2930

Live mode only

As far as I can see, it works fine, animations/transitions are smooth. It behaves better than the 8.1rc2 iso, which freezes the display (and input system) for a minute or two some times after boot, usually during the setup wizard.

2 things that I noticed, but it's the same on the 8.1rc2 iso:

- touchscreen doesn't work at boot

- web page with multiple hw-decoded <video> elements lock up the display (sent an email about it yesterday)

For the touchscreen problem, it's not that the hardware is not supported, I can get the touchscreen working with 'rmmod hid_multitouch' then 'modprobe hid_multitouch'. Something is odd at boot, I can see the touchscreen detected and inputX devices created in dmesg output, but I see it twice: once before ueventd starts, once after. And the inputX numbers are different. I can see the corresponding eventX and inputX for the touchscreen in /sys/class/input, but the eventX entry is not present in /dev/input.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

Hi Mauro,
I review your 18.3.1_oreo-x86 branch of mesa.
I have concern about the two patches:

* Revert "tgsi/ureg: always emit constants (and their decls) as 2D"
What's the exact purpose to revert it?

* Revert "android: enable x86 asm and sse4 for x86 and x86_64"
This seems pointless since you didn't apply the
"android: enable x86 asm and sse4 for x86 and x86_64" from Wuzhen.

Except that, the branch looks promising.
Thank you for the great work!

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Mauro Rossi]

Hi Chih-Wei,

On Friday, December 21, 2018 at 11:09:26 AM UTC+1, Chih-Wei Huang wrote:

Hi Mauro,
I review your 18.3.1_oreo-x86 branch of mesa.
I have concern about the two patches:

* Revert "tgsi/ureg: always emit constants (and their decls) as 2D"
  What's the exact purpose to revert it?

It can be removed, it was sorted out

 

* Revert "android: enable x86 asm and sse4 for x86 and x86_64"
  This seems pointless since you didn't apply the
  "android: enable x86 asm and sse4 for x86 and x86_64" from Wuzhen.

Thanks, I've updated my 18.3.0_oreo-x86 branch

 

Except that, the branch looks promising.
Thank you for the great work!

Thanks to you for your help and support

 

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Regarding my tests with gbm_gralloc + drm_framebuffer the good news is

and I get vulkan anv is again rock stable ok and vulkan radv shows no regression on Mullins, Bonaire, Tonga, Polaris

kernel-4.19 is stable (and Long Term supported)

In 32bit builds I see crashes in libhoudini 8.0.0y seems expecting AES instruction set,

but it may be because I've tested on Core 2 and x3430 (a Quad Core 1156 processor now priced 10$)

which are lacking AES. I did not know libhoudini could have requirements beyond the Androdi ABI x86 ones.

I think most of the vulkan enabled users will use x86_64 build.

One question: does someone in the forum know a good tool to examine thread safety on nouveau code?

Mauro

[Lambdadroid]

I've tested your ISO on a notebook with Intel + NVIDIA graphics and it
seems like the combination gbm_gralloc + drmfb seems to use nouveau
(/dev/dri/card0), whereas drm_gralloc uses i915 (/dev/dri/card1).
Nouveau appears to be broken (a lot of kernel errors), so it does not
boot out of the box anymore, until I delete the nouveau kernel module
(blacklisting via kernel parameters did not seem to work).

I guess there is some extra code in drm_gralloc that chooses i915 over
nouveau. But I'm not sure this is something that should be handled in
drmfb; drm_hwcomposer does not have any such code either. So maybe it
would be easier to check this in the init.sh script and set a system
property to use an other DRM node?

FYI, I'm currently working on a more modern replacement for drmfb that
will solve item (1) (screen mirroring). The way it looks right now it
will only work on Android 9 (Pie) and above, so it's still worth to
continue testing the current drmfb FB HAL.

[Chih-Wei Huang]

Lambdadroid <lambd...@gmail.com> 於 2019年1月2日 週三 上午3:00寫道：

>
> I've tested your ISO on a notebook with Intel + NVIDIA graphics and it
> seems like the combination gbm_gralloc + drmfb seems to use nouveau
> (/dev/dri/card0), whereas drm_gralloc uses i915 (/dev/dri/card1).
> Nouveau appears to be broken (a lot of kernel errors), so it does not
> boot out of the box anymore, until I delete the nouveau kernel module
> (blacklisting via kernel parameters did not seem to work).
>
> I guess there is some extra code in drm_gralloc that chooses i915 over
> nouveau. But I'm not sure this is something that should be handled in
> drmfb; drm_hwcomposer does not have any such code either. So maybe it
> would be easier to check this in the init.sh script and set a system
> property to use an other DRM node?

The problem is, what the primary fb is?
That is, what's "cat /proc/fb"?
Actually drm_gralloc determines which node to use
according to /proc/fb.

> FYI, I'm currently working on a more modern replacement for drmfb that
> will solve item (1) (screen mirroring). The way it looks right now it
> will only work on Android 9 (Pie) and above, so it's still worth to
> continue testing the current drmfb FB HAL.

[Lambdadroid]

On Wed, Jan 2, 2019 at 4:32 AM Chih-Wei Huang <cwh...@android-x86.org> wrote:
>
> Lambdadroid <lambd...@gmail.com> 於 2019年1月2日 週三 上午3:00寫道：
> >
> > I've tested your ISO on a notebook with Intel + NVIDIA graphics and it
> > seems like the combination gbm_gralloc + drmfb seems to use nouveau
> > (/dev/dri/card0), whereas drm_gralloc uses i915 (/dev/dri/card1).
> > Nouveau appears to be broken (a lot of kernel errors), so it does not
> > boot out of the box anymore, until I delete the nouveau kernel module
> > (blacklisting via kernel parameters did not seem to work).
> >
> > I guess there is some extra code in drm_gralloc that chooses i915 over
> > nouveau. But I'm not sure this is something that should be handled in
> > drmfb; drm_hwcomposer does not have any such code either. So maybe it
> > would be easier to check this in the init.sh script and set a system
> > property to use an other DRM node?
>
> The problem is, what the primary fb is?
> That is, what's "cat /proc/fb"?
> Actually drm_gralloc determines which node to use
> according to /proc/fb.

There is only inteldrmfb listed:
# cat /proc/fb
0 inteldrmfb

I'm still wondering if this is something that should be implemented in
Android-x86 (e.g. in init.sh) or in drm_hwcomposer and drmfb
separately. Afaik the fbdev API is mostly obsolete so maybe there is
an other DRM way to check this?

>
> > FYI, I'm currently working on a more modern replacement for drmfb that
> > will solve item (1) (screen mirroring). The way it looks right now it
> > will only work on Android 9 (Pie) and above, so it's still worth to
> > continue testing the current drmfb FB HAL.
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
>

[Chih-Wei Huang]

CC Emil who is the author of drmGetDevices2() in libdrm.

Lambdadroid <lambd...@gmail.com> 於 2019年1月2日 週三 下午6:18寫道：

>
> On Wed, Jan 2, 2019 at 4:32 AM Chih-Wei Huang <cwh...@android-x86.org> wrote:
> >
> > Lambdadroid <lambd...@gmail.com> 於 2019年1月2日 週三 上午3:00寫道：
> > >
> > > I've tested your ISO on a notebook with Intel + NVIDIA graphics and it
> > > seems like the combination gbm_gralloc + drmfb seems to use nouveau
> > > (/dev/dri/card0), whereas drm_gralloc uses i915 (/dev/dri/card1).
> > > Nouveau appears to be broken (a lot of kernel errors), so it does not
> > > boot out of the box anymore, until I delete the nouveau kernel module
> > > (blacklisting via kernel parameters did not seem to work).

HI Lambdadroid,
I saw a similar issue when tested gbm_gralloc + drm_fb on
a Nvidia Optimus notebook, except on my device
i915 is the primary one (/dev/dri/card0, /dev/dri/renderD128) while
nouveau is the secondary (/dev/dri/card1, /dev/dri/renderD129).
However, gbm_gralloc just chose /dev/dri/renderD129 that causes
the device is unable to boot.

I traced the platform_android.c of mesa, in droid_open_device()
it uses drmGetDevices2() to enumerate the dri nodes.
Then I found drmGetDevices2() uses opendir() to enumerate
the dri directory. I think that's the problem --
the order is unspecified.

Then I changed it to use scandir() to sort the nodes
in alpha order:

https://sourceforge.net/p/android-x86/external_libdrm/ci/3f3720fa7229cc2c846619ebcc46597e1c32a49b/

This fixes gbm_gralloc + drm_fb on my Nvidia Optimus notebook.

HI Emil,
Do you see any possible issue to enumerate the nodes
in alpha order? Should I submit the patch to libdrm list?

[erkan sağir]

Hello Mauro, thanks for your work but i did not understand which should i download the "iso" files? How can i boot android x86 in my pc? Can i boot with rufus?
My pc is Lenovo G50-80 with Amd r5 m330 and İntel hd 5500 so how can i enable or chose r5 m330 for vulkan test. How can i open terminal like phoenix os(We should open terminal with F1 and close with F7). I did see that " There is only inteldrmfb listed: # cat /proc/fb 0 inteldrmfb"

[erkan sağir]

I tested your isos but screen glitch

[Chih-Wei Huang]

Emil Velikov <emil.l....@gmail.com> 於 2019年1月11日 週五 上午12:00寫道：

> On Wed, 9 Jan 2019 at 11:28, Chih-Wei Huang <cwh...@android-x86.org> wrote:
> >
> > HI Emil,
> > Do you see any possible issue to enumerate the nodes
> > in alpha order? Should I submit the patch to libdrm list?
> >

> Which device is associated with card0 or card1 can vary across
> reboots, so changing the order it's enumerated won't help much :-(

Ah. In Android-x86 we've implemented a way to load Intel driver (i915)
earlier than other GPU driver (in ueventd) so the order is fixed.

However, I see your point. Thanks!

> Instead, since we want to use the a specific vendor/device, simply
> check the drmPciDeviceInfo which will provide the required
> information.
>
> A generic solution that works everywhere will be hard, if not
> impossible, so one could have a way to override the selection
> heuristics.
> Be that via an android propertly, kernel command line or otherwise.

In drm_gralloc I've tried to map the content of /proc/fb
to the driver name to be opened:

https://sourceforge.net/p/android-x86/external_drm_gralloc/ci/1ffd2c8a4208b4eef1cdbbfcc060952260317510/

Do you think that's a reliable solution?

[Mauro Rossi]

Hi,

On Thursday, January 10, 2019 at 1:12:54 PM UTC+1, erkan sağir wrote:

Hello Mauro, thanks for your work but i did not understand which should i download the "iso" files? How can i boot android x86 in my pc? Can i boot with rufus?
My pc is Lenovo G50-80 with Amd r5 m330 and İntel hd 5500 so how can i enable or chose r5 m330 for vulkan test. How can i open terminal like phoenix os(We should open terminal with F1 and close with F7). I did see that " There is only inteldrmfb listed: # cat /proc/fb 0 inteldrmfb"
 

If you have Intel HD 5000 as primary graphics, blacklisting i915 was the only attempt possible,

you tried and it does not work, so your config is not supported.

Intel HD 5500 should work.

Mauro

[Chih-Wei Huang]

The just released 8.1-r1 has integrated the (experimental) Vulkan support.
Specially thanks to the great work from Mauro and Lambdadroid
to make it happen.

[Chih-Wei Huang]

Emil Velikov <emil.l....@gmail.com> 於 2019年1月14日 週一 下午11:00寫道：

> > Do you think that's a reliable solution?
> >

> I suspect there's a race condition where the second GPU may bring up
> it's fbcon before the first one.
> With the workaround you have, chances are that you will not see the issue.

I found another way to find DRM nodes name of the primary framebuffer driver.
That is, look at the path /sys/class/graphics/fb0/device/drm/.
Regardless of the order in which the drivers are loaded,
it always contains the nodes name of the primary framebuffer (fb0).
I've tested several multi-GPU devices I have.
It just works.

Do you think it's more reliable?

> What I meant with "generic" solution, is that apart from integrated
> Intel GPU one could have one from AMD/OTHER_VENDOR(?).
> In some cases all outputs are connected to the integrated GPU. In
> others the discrete is used for some (DP/HDMI).
>
> So trying to figure out what works where isn't as trivial :-\