Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Test lima support #273

Closed
nandra opened this issue Nov 7, 2019 · 38 comments
Closed

Test lima support #273

nandra opened this issue Nov 7, 2019 · 38 comments

Comments

@nandra
Copy link
Collaborator

nandra commented Nov 7, 2019 •
edited

In poky zeus lima mesa option can be enabled. I plan to test at least glmark2 on orangepi-pc-plus with this extension. My naive steps would be to enable kernel driver for lima and drop sunxi-mali and set all PREFFERED_PROVIDERS to mesa + enable lime PACKAGECONFIG in mesa_%.bbappend.
Do we need something else? Thx
@slapin
Copy link

slapin commented Nov 7, 2019 via email

@nandra
Copy link
Collaborator Author

nandra commented Nov 7, 2019

Yes sunxi-mali is WIP as mentioned in #269 and it's not finished (I think I don't have much graphical experience to finish it ;)). But lima as alternative would be also ok IIRC.

@diegorondini
Copy link

I have a draft non-working patch I can post in the next few days.
lima driver is loading correctly and finds the Mali hardware, display output is ok, but Weston still starts using software rendering (although Mesa is build with lima support).

@nandra
Copy link
Collaborator Author

nandra commented Nov 18, 2019

That is great. Looking forward when you share your results.

@diegorondini
Copy link

Ok, I'm now able to build core-image-weston and have weston starting and using Mesa lima driver on a orange-pi-zero-plus2, so it's a start.
The commit is this one:
Kynetics@99d2314
of course it's a draft, but it's a start we can work on.
Some important notes:

  1. of course commenting out sunxi-mali.inc is not the way to go. My idea is to have something like use-mainline-bsp in meta-freescale (https://lists.yoctoproject.org/pipermail/meta-freescale/2017-March/020284.html) and allow the user to choose by appending to MACHINEOVERRIDE
  2. of course kernel 4.19 doesn't have lima and panfrost, so 5.3 is required. Also support in 5.4-rc needs to be enabled and tested
  3. pam support is recommended to avoid issue about XDG_RUNTIME_DIR not being set at weston startup (e.g. add DISTRO_FEATURES_append = " pam" to local.conf)
  4. remember to have at least an input device connected when system boots, or add require-input=false to weston.ini (https://www.mankier.com/5/weston.ini)

Feedback, comments and contributions are welcome!

@diegorondini
Copy link

I forgot to mention I'm building with everything from master (poky, meta-openembedded, meta-sunxi), not from zeus. Also, I've cherry-picked Mesa 19.2, currently only in master-next:
http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=42671204ede483873379ecbf36b80f9a35118d21
I think it should work also on zeus, but needs testing of course.

@diegorondini
Copy link

Mesa 19.2 is now in master.
I've updated the patch to include CONFIG_CMA and CONFIG_DMA_CMA which was required on some platforms. The patch is now tested on A20 and H5, I will test on H3 as well.

Let me know if you are ok with the idea of using something like use-mainline-bsp for allowing the user to select between mali and lima.

@nandra
Copy link
Collaborator Author

nandra commented Dec 2, 2019

Hi pls create branch with all necessary changes so we can review it. For switching between lima/mali I suggest to create variable like GPU_ACCEL (default mali) and can be changed to lima. @diegorondini what do you think? Thanks.

@slapin
Copy link

slapin commented Dec 2, 2019

I support the solution proposed by @nandra. Also I think we could propose machine feature to core unless there is one already (will require PR).

@nandra
Copy link
Collaborator Author

nandra commented Dec 2, 2019

@slapin you mean add MACHINE_FEATURE for lima handling to oe-core? Thx.

@slapin
Copy link

slapin commented Dec 2, 2019 via email

@diegorondini
Copy link

diegorondini commented Dec 2, 2019 •
edited

Hi pls create branch with all necessary changes so we can review it. For switching between lima/mali I suggest to create variable like GPU_ACCEL (default mali) and can be changed to lima. @diegorondini what do you think? Thanks.

Hi.

The branch is the "use-mailine-graphics" here:
https://github.com/Kynetics/meta-sunxi/tree/use-mainline-graphics
The only real patch for using lima is this one:
Kynetics@b8f6944

Keep in mind we need to be able to do things like this:
https://www.yoctoproject.org/pipermail/meta-freescale/2017-March/020286.html
For example:
PACKAGECONFIG_append_use-mailine-graphics = " lima panfrost"
GALLIUMDRIVERS_append_use-mailine-graphics = ",kmsro"
https://www.yoctoproject.org/docs/2.7.1/ref-manual/ref-manual.html#var-MACHINEOVERRIDES

I'm not sure this can be done with MACHINE_FEATURE without writing a lot of code.

@slapin
Copy link

slapin commented Dec 2, 2019 via email

@diegorondini
Copy link

Well, settings like these are overrides, they can use machine features. I don't see a lot of code here, please elaborate.

MACHINE_FEATURES are not part of OVERRIDES:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n737
If they are not in OVERRIDES, you would need to write boilerplate code, not needed if using MACHINEOVERRIDES.
If you think this is not the case, please provide a working example of what you are thinking of.

We can also use conditionals and also conditionally include .inc files. Try grepping various meta-stuff.

This is possible as well using MACHINEOVERRIDES as I proposed. Do you have comments about the meta-freescale links that I provided?

Also you will need to set up GALLIUMDRIVERS var (if lima is gallium driver, need to check) regardless in case of lima use. the _append would be useful if we had several drivers to look for depending on some configuration, but in our case lima is the only one, unless we expect user to override this var in local.conf too.

We do have panfrost in the picture as well, used by Allwinner H6. Open drivers can live peacefully together installed in the same OS as in regular distros, the only conflict is between vendor (mali) and community (lima, panfrost) drivers.

@nandra
Copy link
Collaborator Author

nandra commented Dec 3, 2019 •
edited

@diegorondini meta-freescale have quite complex stuff for setting up machine overrides IIRC. Not sure if we need it.

What about create variable: MAINLINE_GPU = "lima" and then you can check in mesa not by _append but with

bb.utils.contains('MAINLINE_GPU',     'x',     'y')

logic. I know it's not nice but as we don't have common machine feature (as discussed before) it's the only way to go. Or we can write some small class helper which will add lime to OVERRIDES as done in meta-freescale but not sure if it's worth to spend time on it.
Also look on meta-raspberrypi vc4graphics MACHINE_FEATURE it's what I meant to implement also for our case.
Thanks.

@slapin
Copy link

slapin commented Dec 3, 2019 via email

@diegorondini
Copy link

Hi, ok thanks for you suggestions.
Of course we don't need the complex setup of meta-freescale. I'll have a look at meta-raspberrypi to get some ideas.

Of course I'm short on time as well, so it may take some time.

@smzahraee
Copy link

I use mesas and lima with buildroot-2019.11 (kernel 5.3.7),it works great on my Cubieboard2 and i guest other boards are fine
kmscube and glmark2 work great
now for yocto it is better to start with a patch for Dunfell branch, because Zeus is now stable

@nandra
Copy link
Collaborator Author

nandra commented Jan 1, 2020

@smzahraee thanks for sharing. Waiting for @diegorondini patch and then hopefuly we will merge it so also yocto can have same support as buildroot. BTW did you try (or not sure if it's even possible) to have qt5 accelerated with lima? Thanks and Happy New Year

@smzahraee
Copy link

i tested qt5.12 examples with wayland/weston
there is few problem,
qt.qpa.wayland.backingstore: Delivering update request through fallback timer, may not be in sync with display
and
gpir: if nir_cf_node not support

that cause not showing window correctly, but i think next mesa releases(mesa mesa-19.3.1 ) may fixed them

kmscube worked fine
but glamrk2 in middle of test get segment fault

i am reviewing mesa3d patches for my problems but not found anything yet

@nandra
Copy link
Collaborator Author

nandra commented Jan 4, 2020

@smzahraee what about qt5 and gles? Did you try also this one? Thanks.

@slapin
Copy link

slapin commented Jan 5, 2020 via email

@smzahraee
Copy link

@smzahraee what about qt5 and gles? Did you try also this one? Thanks.

every things is okay,except that

  1. hardware cursor which is not implemented on drm and should set QT_QPA_EGLFS_KMS_CONFIG with following configs:
{
  "device": "/dev/dri/card0",
  "hwcursor": false,
  "pbuffers": true,
  "outputs": [
    {
      "name": "HDMI1",
      "mode": "1920x1080"
    }
  ]
}
  1. text inputs not showing correctly
  2. still get gpir: if nir_cf_node not support on some examples
  3. get Framebuffer size format is invalid.

@smzahraee
Copy link

While you're at it could you please provide glmark2 results for both lima and mali drivers (the output/log of these)? Thanks a lot for your work!

glamrk2 failed on mesa3d (segment fault)

@slapin
Copy link

slapin commented Jan 5, 2020 via email

@smzahraee
Copy link

@slapin
glmark2-es-drm results:
glmark2.log

@smzahraee
Copy link

smzahraee commented Jan 5, 2020 •
edited

@slapin
glmark2-es-drm results:
glmark2.log

here is resolved problem in mesa mainline:LINK

I think possible qt problems will solve by this commit
so i expect next mesa release (20.1.0 maybe) will solve that errors

@slapin
Copy link

slapin commented Jan 5, 2020 via email

@slapin
Copy link

slapin commented Jan 5, 2020 via email

@smzahraee
Copy link

@slapin
they specified glmark2 problem is fixed. are sure this problem was not solved?

qt has some bugs with text edits i dnot know is this qt problem or mesa problem. but other features work well

@nandra
Copy link
Collaborator Author

nandra commented Jan 5, 2020

@smzahraee can you share links please with glmark2 problem fixed? Thanks.

@smzahraee
Copy link

@smzahraee can you share links please with glmark2 problem fixed? Thanks.

here is resolved problem in mesa mainline:LINK

@nandra nandra mentioned this issue Jan 26, 2020
Merged
@diegorondini
Copy link

Not there yet, but most of the work left should be on sunxi-mali.inc now:
Kynetics@9528907

@diegorondini
Copy link

diegorondini commented Mar 3, 2020 •
edited

See pull #285 . I haven't tested a build with the mali driver, as I have no interest for it, but there's no variable change if use-mailine-graphics isn't defined.

@diegorondini
Copy link

The code is merged, I think this issue can be closed.

@nandra nandra closed this as completed Apr 29, 2020
@nandra nandra mentioned this issue Mar 12, 2021
Closed
@nandra nandra reopened this Mar 12, 2021
@nandra
Copy link
Collaborator Author

nandra commented Mar 12, 2021

@smzahraee can you please share how you run qt5 app using lima and mesa? I build kernel with lima and enable necessary config for mesa. glmark2 + kmscube works but I cannot make qt5 app working with eglfs. Or do I need to use wayland? If you can please share I'll put it on README so anyone else can benefit. Thanks.

@diegorondini
Copy link

It doesn't make sense to reopen this issue, especially looking at the original description.

eglfs is specific to Qt, so even if it doesn't work, it doesn't mean EGL support is not working. @nandra I think it's better to handle your problem in a separate issue.

@nandra
Copy link
Collaborator Author

nandra commented Mar 12, 2021

@diegorondini ok agree. Sorry.

@nandra nandra closed this as completed Mar 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slapin @nandra @diegorondini @smzahraee