DPI performance improvement

[tvjon]

Hence, not an issue, but...

Interesting. Can any of the team comment on if this release would impact the DPI/vga666 display?

Omxplayer has usually played files fine, but things like dispmanx based slide shows or just jpeg displays have been taking several seconds to start displaying, along with a couple of seconds delay between subsequent pictures.

I wasn't sure if it was a regression or what, as it's been slow for a long time. Anyway, display 4 now seems as responsive as display 0, thank you.

[popcornmix]

The DPI output is handled in hardware so shouldn't be any less efficient than HDMI.

I think you'll have to explain exactly what "this release" is, what you are comparing it to, and what app you using that may or may not be slower.

Anyway, display 4 now seems as responsive as display 0

I'm not following what the issue is.

[tvjon]

open.zip

$ vcgencmd version

Mar 24 2017 13:57:27 Copyright (c) 2012 Broadcom version 7e9eb8ef90a1cfb42aca39c27807d2d145a403a1 (clean) (release)

Using:

https://github.com/HaarigerHarald/omxiv

as an example.

$ omxiv.bin -d 0 Pictures/

promptly starts to display the folder contents, & -> key held down flies through the pictures.

$ omxiv.bin -d 4 Pictures/

however, has a delay in startup. & delays between the display of subsequent pictures, or skips pictures.

This happens with some other dispmanx applications too. Omxplayer though, playing video, seems ok via both interfaces.

I understand that DPI/vga666 is using hardware, hence my surprise at the delay.

Further testing suggests it may have been a coincidence updating firmware because of other software that was running after the update.

For example I notice today that if I run another dispmanx application, say a very simple one like the attached, which just opens the display:

$ ./open 4

then returns, display 4 responds as expected running omxiv.bin again.

[tvjon]

I've done some more testing - hardware related.

That simple open program only opens the display, not close, as you've doubtless noted.

Attached is a PISCOPE (thank you joan, saved me trying to find my 'scope probe) trace of the DPI pins after running

./open 4

Note that H & V sync's are still active.

If I now run

omxiv.bin -d 4 Pictures/

I get similar performance to the default HDMI display, so no delay producing the first image, or significant delays between pictures.

So, keeping alive H & V sync's for DPI is more like the situation with the default display 0. Obviously the sync's don't get turned off display 0 other than power off / on.

I don't, of course, have any idea how not closing display 4 affects other internal structures within VC4.

[Ruffio]

@tvjon, @popcornmix what is the next step with this issue?

[popcornmix]

@tvjon does the problem go away if you run with -b option?

[tvjon]

That does indeed work.

[popcornmix]

So what is happening is dispmanx_display_open/dispmanx_display_close calls are reference counted and the display is powered down/clocks stopped when it reached zero.

The video_render component is internally doing an open call when asked to display an image and a close when asked to remove an image.

When scrolling through the images the frequent dropping of the display clocks causes the display to drop out causing the delay you have reported.

It turns out that a bug in the -b handling of omxiv (it calls vc_dispmanx_display_open without calling vc_dispmanx_display_close) avoids this issue.

It doesn't happen on HDMI because the normal console framebuffer also calls open. It won't occur on the DPI display if it is the primary display (i.e. with display_default_lcd=1) for the same reason.

I need to think about whether disabling the display when the reference count reaches zero is actually the best choice.

One thing I spotted with omxiv -b is that the lack of matching opens/closes has a permanent effect - you can now run omxiv without -b subsequently and the display won't power down.

Ideally individual processes shouldn't be able to have a affect on display behaviour beyond their lifetime.

Removing the reference counting would be one solution to this - the other would be to have an exit handler that closes any opened displays (but that wouldn't help this reported issue).

[tvjon]

A nice comprehensive explanation, thank you.

"One thing I spotted with omxiv -b is that the lack of matching opens/closes has a permanent effect - you can now run omxiv without -b subsequently and the display won't power down."

Yes, I discovered this too after further experimentation.

I haven't as yet reported a problem to omxiv's writer, as I thought it better to wait for your thoughts on the problem.

It's often useful to allow creativity in an application, but not if it influences what happens outside that program, as you mention.

[popcornmix]

Latest rpi-update should fix the reference counting between separate applications. (i.e. you won't see a permanent fix from running omxiv -b once).

We're still discussing the best solution for the display powering down when app is running. (A workaround for now would be to call display open at start of omxiv and display close at end).

[tvjon]

I'm just wondering about the reference counting... I ran "splash_video" earlier on display 4 (vga666), & realised that it misses the first iteration of a multiple loop run, observed by setting, for example, 3 for the count, but for the first loop time the display is black. It does appear for the next 2 iterations.