Crash when using Nvidia cards with the SDL driver

[luckcfm]

Hi, I'm trying to run the example on linux (ubuntu 18.04), and when I run the micropython from https://github.com/littlevgl/lv_micropython I get only a black screen and the script stop running without any alert or errors.

This is the code that Im trying with the master branch.

import lvgl as lv
lv.init()
import SDL
SDL.init()

# Register SDL display driver.

disp_buf1 = lv.disp_buf_t()
buf1_1 = bytearray(480*10)
lv.disp_buf_init(disp_buf1,buf1_1, None, len(buf1_1)//4)
disp_drv = lv.disp_drv_t()
lv.disp_drv_init(disp_drv)
disp_drv.buffer = disp_buf1
disp_drv.flush_cb = SDL.monitor_flush
disp_drv.hor_res = 480
disp_drv.ver_res = 320
lv.disp_drv_register(disp_drv)

# Regsiter SDL mouse driver

indev_drv = lv.indev_drv_t()
lv.indev_drv_init(indev_drv)
indev_drv.type = lv.INDEV_TYPE.POINTER;
indev_drv.read_cb = SDL.mouse_read;
lv.indev_drv_register(indev_drv);

# Create a screen with a button and a label

scr = lv.obj()
btn = lv.btn(scr)
btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text("Hello World!")

# Load the screen

lv.scr_load(scr)

[embeddedt]

By default, MicroPython exits as soon as the script finishes running (AFAIK). To avoid that, you either have to add an infinite loop at the bottom of the script (or some other blocking operation), or run it on the REPL so that MicroPython doesn't exit immediately.

[luckcfm]

@embeddedt yeah I figure that out and add an utime.sleep at the end of the script, but my screen is black, with nothing on it.

[amirgon]

Hi @luckcfm !

Let's start by making sure the REPL (interactive console) is working. When you run micropython without any parameter, do you get a prompt? Something like:

MicroPython v1.11-435-g2940838-dirty on 2019-09-27; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> 

If you do, try the following:

• Click CTRL+e
• Paste the simple example code above.
• Click CTRL+d

You should get this:

Let me know how far you got.

[luckcfm]

@amirgon Thanks, yeah the prompt is working fine. I just run the code with ctrl + e and ctrl +d and got segfault.

[luckcfm]

Heres an screenshot of the erro.

[luckcfm]

Ok, I ran a snippet at my other ubuntu (16.04) and it worked. Maybe this is a problem with 18.04?

[embeddedt]

Maybe this is a problem with 18.04?

Could be, I don't use Ubuntu 18.04 yet, and I'd like to avoid making a full-on VM, so I'm unable to debug it easily (unless it can be reproduced in a Docker instance).

[amirgon]

@amirgon Thanks, yeah the prompt is working fine. I just run the code with ctrl + e and ctrl +d and got segfault.

In that case, the next step is to build it with debug symbols (clean the build, and build again with DEBUG=1 on the make command line). Then run gdb micropython.

You should get a stack trace that could shed some light on what's going on.
My wild guess would be - something with the SDL driver.

[embeddedt]

Then run gdb micropython.

And then type run in the gdb prompt to actually run MicroPython.

[luckcfm]

Thanks guys. I ran with the gdb command and got an error on my nvidia module, which lead me to think that my gpu was the problem and then I switched to intel gpu, and now is running ok!! So apparently, this is an issue with nvidia cards.

[luckcfm]

Here is the message from gdb.

[embeddedt]

So apparently, this is an issue with nvidia cards.

Weird. I doubt that this pertains to LittlevGL/MicroPython itself. It's probably an issue with SDL and Nvidia cards. (There is a switch in our driver that disables hardware acceleration on platforms like VMs, but I don't think MicroPython enables it.)

Out of curiosity, do you know whether you have run other SDL-based programs and they have worked?

[amirgon]

@luckcfm Could you send us the stack trace? (After gdb stops on the Segmentation fauld, enter: bt full and send us the output)

[luckcfm]

Sure, no problem, here it is

[embeddedt]

It crashes somewhere inside the Nvidia driver and not our code, but no further debugging information is available, which makes it nearly impossible to pinpoint the issue. I assume you are using the latest drivers?

[luckcfm]

@embeddedt yes, its something with nvidia, maybe with SDL and nvidia. I'm running the latest drivers (one of the reasons for using 18.04). But ok, its easy to change to intel and I only need to run in my machine to create screens. Thanks for the help!

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[embeddedt]

I'd like to solve this issue, as it's been reported again on the forum (and, now that I have an Nvidia card, prevents me from testing anything on the Unix port).

It seems that the issue doesn't happen with the standard PC simulator driver, but only with the MicroPython one. The most obvious difference I see between the two is that the MicroPython driver does not use an SDL thread to do refreshing, but does it on the normal MicroPython thread instead.

@amirgon Is there a reason why we can't use the standard PC simulator driver from lv_drivers for MicroPython as well? That seems like the fastest way to solve this issue and would also reduce code duplication.

(cc @tve)

[amirgon]

@amirgon Is there a reason why we can't use the standard PC simulator driver from lv_drivers for MicroPython as well? That seems like the fastest way to solve this issue and would also reduce code duplication.

• In C it's very common you set parameters as compile time constants ("defines"). But in Micropython the idea is that you build the firmware once, and configure (almost) everything on runtime, in Python code. So one difference in Micropython's SDL driver is that it allows setting the width/height on runtime while the "standard" driver doesn't.
• You added some Emscripten patches to the SDL driver, were they added the same way in lv_drivers?
• More than a year ago I specifically changed the SDL driver to be single threaded and use the same thread as Micropython. I don't remember exactly the reason now (unfortunately I didn't elaborate on that on the commit message) but there was probably some reason for that, probably to fix some problem.
  It may be related to the fact that Micropython lvgl bindings are not thread safe, but we don't require locks. This works under the assumptions that everything is single threaded, such that a callback from SDL mouse event for example would only happen when we expect it to happen.

[embeddedt]

You added some Emscripten patches to the SDL driver, were they added the same way in lv_drivers?

The Emscripten patches are conditioned on __EMSCRIPTEN__, so I doubt they would change the behavior. I will double-check though.

I specifically changed the SDL driver to be single threaded and use the same thread as Micropython.

I see. The threading may not be the issue; it was just my initial guess. A workaround might be to use the nouveau drivers instead; I'll have to see if there's an easy way of switching back and forth from that without having to edit configuration files. Obviously the current "switch to Intel" method is not very practical, especially on a desktop PC where the dedicated graphics essentially take over.

We could try and put together a test case and file an upstream bug with SDL, but considering the obscurity of the proprietary Nvidia libraries, and the fact that I have not been able to find a single other instance of this issue on the web, I doubt there will be any priority to fix it.

[embeddedt]

@tve In the meantime, the v6 and v7 versions of the web simulator are alive and well, and aren't that much more limited than the PC simulator if you're just looking to experiment with the API. Do be aware that v7 runs significantly closer to native speed on the web than v6 does.

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[embeddedt]

@amirgon Are there any features missing from the web simulator that one would plausibly want in the Unix port? The best workaround here might just be to use the web simulator, since it doesn't suffer from this issue and should work on any Unix platform.

[amirgon]

The best workaround here might just be to use the web simulator, since it doesn't suffer from this issue and should work on any Unix platform.

@embeddedt The Unix port by itself is important for number of reasons:

• The user can build the Unix port fast and easily on any branch or version without any special prerequisites such as Emscripten. The web simulator deployed on LVGL server is only aligned to one branch at a certain point in time and could be missing features or bug fixes
• There are many things that are set during compile time. Anything in lv_conf.h for example. The users may need to change some macros and rebuild the simulator.
• The Unix port is not only a "simulator", it's a platform. It can be used on many single board Linux computer with either Frame Buffer or SDL, and there may be applications even for PCs.

So my opinion is that the web simulator is not a replacement for the Unix port.

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.