Raspberry Pi 2 - dispmanx issues

RetroArch Linux devices
#1

Hi All,

I’ve been fiddling with the dispmanx video driver as it is apparently capable of slightly better performance and possibly improves input latency, but I’ve ran into a couple of issues - not sure if they’re general issues or something weird with my hardware/setup?

[ol] [li]Showing the RGUI is unstable. The display appears to crash, showing a blank screen (and a ‘no signal’ message on my HDTV), with the game running in the background. If I use hotkeys to close the menu, the display returns. This is all very inconsistent, though - rarely the menu shows fine, and other times it shows for a few seconds and then crashes, and other times it appears for about 1 frame before the crash. Because the process doesn’t halt (just the video display), I’m not sure how to get an error message - is there a way?[/li][li]It appears that an equivalent effect to HW Bilinear Filtering is always in place regardless of the RGUI/.cfg setting (and turning it on has no additional effect either). I’ve tried using different retroarch render resolutions but it doesn’t seem to make a difference.[/li][/ol]

Both these issues happen in any core I’ve tried (although I’ve been nes/fceumm mostly for testing), and I don’t have any other instability with my system running other cores with other video drivers.

It would be really useful if anyone else had a pi or pi 2 they could experiment with this driver so I could rule out my hardware or config - cheers :slight_smile:

#2

Very late, but I can confirm this. Screen permanently blurry. I also can’t get shaders to work. It’s really to bad, as this driver removes all noticeable latency/lag on my Pi3. I was about to give up on it. The newest retropie has the driver complied in. So I was able to test this with linuxraw for joy input.

#3

@dankushions: I did this driver time ago, and back then I’d swear it was stable: I remember testing it by going into RGUI and back to the game a lot of times. Are you running it without an X server running? About input lag, as this driver is right now it uses a double-threaded, triple-buffering system I implemented so the main thread wouldn’t have to wait for vsync (but waiting for vsync IS being done so things are smooth), so input lag should be the same of the OpenGL ES renderer, not more, not less. I can reduce it to a simple double-buffer, but then emulation speen will suffer slightly: things will be equally smooth regarding movement, but emulation will start having problems when it uses a high CPU percentage. This could be compensated if RetroArch would allow zerocopy screen updates, but it doesn’t allow that currently, because it passes a pixel array pointer to the screen update functions and we have to copy the pixels from there: no way to tell RA “put pixels in this address where I have mapped a video buffer”.

@tekn0: Shaders won’t work with this driver. How could they? Shaders are for OpenGL renderers, and there’s no OpenGL involved here, just direct access to the 2D API on the Pi. Also, screen is blurry because of the algorithm dispmanx uses for scaling by default. If you find how to disable it, I’ll be happy to add a call to it in the code so the driver honors the “HW bilinear filtering” option.

Also, the Pi is getting KMS/DRM support, so dispmanx will eventually “vanish” when Raspbian starts booting in KMS mode :frowning: But all is not lost: I have done a KMS/DRM driver, but I am having problems getting it to work as fast as the dispmanx one because the KMS/DRM infraestructure lacks hardware blitting so I have to blit each line individually (some cores have things betweeen scanlines, like pce-fast or gambatte…), which forces me to do a LOT of memcpys per frame as things are. I have asked the VC4 driver developers here:

…but I am still waiting for ideas or solutions.

NOTE: I have just built the latest RetroArch from github, and I have gone into RGUI for like 100 times and back into the game running on a core, and things look perfectly fine here. I can not replicate the menu problems you guys are seeing. Can you give me your video mode and GPU memory in config.txt? If it’s not configured then tell me what fbset says. I can try running at the same resolution as you are. Currently I am at mode 2/39, which is DMT 1360x768.

#4

@tekn0 the RGUI instability should be fixed now in retropie. see https://github.com/libretro/RetroArch/issues/2562 - i haven’t used this driver in a while but if it’s unstable again in retropie can you update that call? maybe the previous fix is needed again.

@both the smoothing issue is mentioned here https://github.com/libretro/RetroArch/issues/2641 - there’s a sort-of workaround, but it’s via sending system commands which isn’t very elegant. eg if there was a crash the scaling wouldn’t return to the previous (?). also, it’s been a while since i checked but i think other dispmanx software such as mame4all (https://github.com/RetroPie/mame4all-pi) seem to be able to scale without smoothing, so maybe there’s a ‘proper’ way? i tried looking at the code but didn’t get very far obviously :slight_smile:

#5

@dankcushions: mame4all-pi uses GLES for rendering (on a dispmanx EGL context, but it renders on GLES), so it simply sets nearest texture filtering. With the direct dispmanx driver it’s not possible since we don’t have GL “textures”, simply a bitmap being uploaded to the GPU using Broadcom’s dispmanx API.

EDIT: I have opened an issue on the Raspberry Pi kernel repository to ask directly about it:

Let’s home there is a way…

#6

[QUOTE=vanfanel;41013]@dankcushions: mame4all-pi uses GLES for rendering (on a dispmanx EGL context, but it renders on GLES), so it simply sets nearest texture filtering. With the direct dispmanx driver it’s not possible since we don’t have GL “textures”, simply a bitmap being uploaded to the GPU using Broadcom’s dispmanx API.

EDIT: I have opened an issue on the Raspberry Pi kernel repository to ask directly about it:

Let’s home there is a way…[/QUOTE]

thanks for the info! that makes sense. yeah, good idea on the git issue - there surely must be a way. it would be a really cool feature for a whole bunch of stuff that uses dispmanx for scaling.

#7

@dankcushions: a bit offtopic but, do you have any evidences that linuxraw input driver should produce less input lag than udev? Any idea on why?

#8

i don’t know too much about input drivers, but it doesn’t seem likely to be any measurable benefit even if it is closer to the ‘metal’ (?)

one of the frustrating things about input lag is that every so often someone here or elsewhere does a few tests with input lag (with a high FPS camera or whatever), but they only test a few scenarios and then give up :confused: i don’t think i’m any wiser about where input lag comes from even on relatively ‘closed’ systems like the raspberry pis, but i guess it’s probably several contributing factors.

#9

@dankcushions: bilinear filtering can now be enabled/disabled on the dispmanx driver and it seems to work fine here :slight_smile:

#10

@vanfanel awesome :slight_smile: great job! i’ll give it a test soon on my pi3

#11

Tested! Works great :slight_smile:

#12

Could you test input lag and tell me how good this dispmanx driver feels vs other options? I seem to recall you have equipment for that (high-refresh camera etc).

#13

not me, sorry :frowning: