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.

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

Add VC4 open source driver support #2093

Open
gizmo98 opened this Issue Aug 21, 2017 · 51 comments

Comments

Projects
None yet
10 participants
@gizmo98
Copy link
Member

gizmo98 commented Aug 21, 2017

I open up a new issue because VC4 open source driver support can be used with Raspbian Jessie and Stretch. Raspbian Jessie support should be discussed here: #2091

Pros:
-Open Source Driver. It is possible to fix bugs or do feature requests upstream
-OpenGL 1.4 and 2.1 support
-Raspbian behaves like a standard Linux installation with MESA libs
-KMS support. Run everything headless without X11

Cons:
-DispManx hardware upscaling dows not work. KMS seems to have scaling options as well. SDL2 kms driver has not implemented upscaling (yet).
-tvservice does not working. Do we need runtime resolution modifications if everything runs fast enough?
-Requires more system flag(s) and further complicates some of the modules.

Prerequisites:
-raspi-config: enable FULL-KMS-VC4
-It is possible to build SDL2 with Kernel Mode Switching (KMS) support or X11 support. I build SDL2 with KMS support because applications can be run without X11. (--enable-video-kmsdrm)
-RetroArch can be build with KMS support (--enable-kms --enable-egl --disable-videocore)
-RetroPie-Setup naming convention: is a additional flag needed? (kms, vc4 or something else? KMS can be used with other GPUs as well)
-Try to get other emulators running (reicast, lr-ppsspp, ppsspp)

Current state:
-SDL2 runs with kms support
-EmulationStation runs
-Retroarch runs. GLSL shaders from libretro/glsl-shaders can be used
-lr-ppsspp, lr-mupen64plus and lr-parralel run
-mupen64plus runs
-All non GL libretro cores should run

Current problems:
-No hardware upscaling if SDL2 is used (mupen64plus)
-No runtime resolution switch option

WIP:
https://github.com/RetroPie/RetroPie-Setup/compare/master...gizmo98:rpi-kms?expand=1

@gizmo98 gizmo98 added the enhancement label Aug 21, 2017

@dankcushions

This comment has been minimized.

Copy link
Contributor

dankcushions commented Aug 21, 2017

cool!

DispManx not working

at least for retroarch, i think drm_gfx is supposed to replace this when using the new driver: libretro/RetroArch#3181

i wonder what the performance/latency is like with it...

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 21, 2017

What about the fake KMS mode - isn't that supposed to facilitate compatibility with tvservice, etc?

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Aug 21, 2017

Thanks.

Additional Cons: Requires more system flag(s) and further complicates some of the modules.

I assume you are thinking to have this as a source only "option" for those that want to play with it? Something we could add in the future I guess, but I don't think we need to include this yet.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 21, 2017

@joolswills
It's just a test balloon. I don't know were it ends up. If the open source driver has any advantage we could consider to add it in the future. Every new MESA release contains better VC4 drivers.

KMS support is not Raspberry Pi dependent. If we can build SDL2 and RetRoarch with KMS support we can run RetroPie-x86 without X11. The GPU driver should support KMS (Intel, Nouveau).

I would like to add at least a new "kms" flag ;)

@dankcushions
Thank you for the info. I will add and test "plain_drm".

@psyke83
As i understand fake kms is a mix of X11/OpenGL and Dispmanx/tvservice. You cannot use the new OpenGL driver without X11 and you cannot use drm/kms.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 21, 2017

@dankcushions
plain_drm seems to run fine. lr-mupen64plus seems to run on par with old driver.

Install instructions:

  1. Download and install a Raspbian Stretch Lite image.
  2. Run sudo raspi-config after first boot and select "FULL KMS GL" driver.
  3. Run sudo raspi-config and select boot to console without login.
  4. Run sudo apt-get update && sudo apt-get upgrade.
  5. Run git clone --depth=1 -b rpi-kms https://github.com/gizmo98/RetroPie-Setup.git.
  6. Run cd RetroPie-Setup and sudo __platform=rpi3-mesa ./retropie_setup.sh.
  7. Install Core packages
  8. Install Cores (i only tested snes9x 2010, lr-mupen64plus and mupen64plus)
  9. Run emulationstation

@gizmo98 gizmo98 self-assigned this Aug 22, 2017

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 22, 2017

Goldeneye seems to run quite well with lr-mupen64plus. lr-parallel seems to run better as well (less glitches). I need to test lr-reicast and lr-ppsspp.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 22, 2017

Thanks for the reply. I tested your branch briefly last night and it's indeed promising. The plain drm retroarch driver doesn't work with fake kms, but the gl driver (and emulationstation) does.

Fake KMS enables tvservice support; I guess it's unavoidable to lose this functionality with the full KMS driver since we're not supposed to rely on vendor-specific methods for modesetting with KMS. Aside from the fake KMS, I noticed some odd jpg-style artifacts on some areas of pixels with the plain drm driver, almost as if it was playing lossy-compressed video rather than displaying raw output.

With the GL driver, performance seems OK. Apart from shaders not working, the xmb text shadow no longer seems to cause any slowdown compared to the Broadcom libraries. Quake and Doom performance seems fine, and when I have some free time I'd like to test lr-pcsx-rearmed as well as N64 (as you've already tested).

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 22, 2017

Sounds good! 👍
Update the script (sudo git pull) to get lr parallel support. Lr-ppsspp and lr-reicast are not supported atm. Makefiles need some modifications. I remaned platform to rpi3-mesa. So please run retropie setup with __platform=rpi3-mesa.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 25, 2017

@gizmo98

I've seen your recent modifications - you're still linking against the wrong libraries. Moving forward, it's necessary to link against the brcmX libraries when you intend to use the vendor libraries. The original names will break stretch, whereas the new library names have been packaged on jessie since the 1.20160921-1 firmware release (along with the original named libraries). Building against the new libraries will work fine for jessie users who are up to date (and future jessie packages may remove the originally-named libs, for all we know).

Using the new names for the vendor stuff is evidently the way that the foundation wants to proceed. The next RPI firmware packages will include the missing pkgconfig to allow automake detection, but only for the vendor libraries using the new names: raspberrypi/firmware#857

I'm unsure if the pkgconfig is ever going to be backported to jessie, so the automake detection is not guaranteed on jessie (unless we intervene via the Retropie-Setup script by adding the missing pkgconfig when necessary).

PS. As you said, lr-parallel indeed works pretty well, and more of the video rendering options seem to function in games (whereas the vendor libraries only seem to work consistently with "rice" for me). lr-pcsx-rearmed also works pretty well; performance seems about the same as the vendor libraries even with the high resolution option enabled, but I thought I was seeing some slight microstutters at times.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 25, 2017

@psyke83
I don't intent to use the old vendor libraries. They do not support mainline kms and drm. I use mesa 13 VC4 libs which can be found under /usr/lib/arm-linux-gnueabih/. I have only added additional "mesa" or "kms" options so far (libretro retroarch/cores). There should be no regression but there should be also no improvement over the current vendor lib state. You can even rename /opt/vc and my branch will still build and run everything fine.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 25, 2017

Yes, I understand your intent. I'm just bringing it up in case you eventually do PRs to upstream projects. For example: https://github.com/gizmo98/libretro-ppsspp/commit/16a08a87c23c915ec1039841228e1947ff40a363

This won't work on stretch when building against the vendor libs. Since you're trying to maintain compatibility, the vendor case needs to be:
GL_LIB := -L/opt/vc/lib -lbrcmGLESv2

Same goes for any instances of -lVG or -lEGL. This will need to be sorted out correctly in several projects in order for stretch to work (and let's be honest, KMS with VC4 is not a good replacement until we can do equivalent modesetting and utilize the OMX decoders for video playback).

You're doing good work sorting out the mesa compatibility and it's definitely worth more testing, I'd just like to see the vendor stuff fixed properly too since stretch compatibility is a worthwhile goal.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 25, 2017

@psyke83
I think we should wait until @joolswills has come up with a raspbian stretch support solution which contains support of renamed vendor libs. It is not good if we change anything and it does not fit afterwards.

@rtissera

This comment has been minimized.

Copy link

rtissera commented Aug 27, 2017

Well I am experiencing with similar KMS stuff (baked into upcoming SDL 2.0.6) in order to port RetroPie to Rock64 board (RK3328) here : https://github.com/rtissera/RetroPie-Setup/tree/rock64

Had a similar approach so I'm all in for "kms" flag implementation.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 27, 2017

I would suggest another way to detect the mesa driver. Add to scriptmodules/system.sh in the section to detect Raspbian quirks:

if egrep -q "^dtoverlay=vc4-(f|)kms-v3d" /boot/config.txt; then
    __platform_flags+=" mesa"
fi

But if Jools ever wanted to provide two sets of binaries, then either $__platform or $__os_codename would need to be different in order to discriminate different binaries.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 28, 2017

Looks good! I just need to think about kms support for other platforms. In the end we need at least a kmsdrm/kms flag.

Just for information lr-ppsspp is running now. I have opened an Retroarch issue to address the shader problem. The driver should be capable for Retroarch shaders. GLideN64, lr-mupen64plus and lr-ppsspp run fine so there should be appropriate GLSL support.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Aug 28, 2017

Yes, the kms flag would be useful & could easily be added there too. The isPlatform function will match anything in the platform flags. In my private testing, I've also set the pkgconfig support here (which will be added to the -dev package in the next firmware: RPi-Distro/firmware@2440d33)

Something like the following seems like a good idea no matter whether or not vc4 is going to be ready for mainstream testing:

if egrep -q "^dtoverlay=vc4-(f|)kms-v3d" /boot/config.txt; then
    __platform_flags+=" mesa kms"
else
    __platform_flags+=" dispmanx"
    export PKG_CONFIG_PATH="/opt/vc/lib/pkgconfig"
fi

Maybe it's not even necessary to make the environment variable a conditional, as the .pc files previously conflicting with mesa's libraries will not be present. Though I'm not sure if any software would realistically need to link against any of the other Broadcom libraries when using the VC4 driver.

PRs sent to upstream projects shouldn't hardcode libraries anymore. There needs to be agreement on how to best select dispmanx/vendor (brcmX libs) vs KMS/vc4 (mesa libs) in the build, and get rid of the hacks that rely on detecting files in /opt/vc/lib. A good step towards reducing this complexity will be to start taking advantage of pkgconfig being present in future firmwares.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Aug 31, 2017

Current shader files can be loaded if retroarch is build with --enable-opengl. All OpenGL cores have to be build with OpenGL support as well. lr-mupen64plus will not run because GLideN64 needs at least OpenGL 3.3.

Retroarch with GLES support does not support our current shaders. Some shaders from libretro/glsl-shaders can be used. There is a newer version of crt-pi.glsl which runs.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 1, 2017

You've figured out the shader issue - good work. I think you may have misunderstood the intent of the fkms mode based on your reply to me a while back - it's useful to facility compatibility between the vc4 driver and the vendor libraries (including tvservice). It doesn't break KMS as far as I can see.

I'm testing it right now; ES and RetroArch (at least with the GL driver, not sure about plain drm) appears to work absolutely fine. Modesetting via tvservice works, and unlike with the vendor graphics driver, changing modes doesn't blank the framebuffer, so ES doesn't require a restart for the mode change to take effect. Another positive upside is that anything requiring a framebuffer display, such as runcommand dialogs, will also display properly.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 2, 2017

This sounds great! I think i read somewhere GL does not work headless if fkms is used but i didn't test it actually.

I will dig around to get reicast and sdl2 (hardware) upscaling running. I have not tested omxplayer. The only other missing feature should be ppsspp standalone then.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 2, 2017

I've already tested omxplayer. Under full kms mode, only audio works, but video displays just fine when fkms mode is enabled. It renders the video over a running ES session; I can even changing the opacity to see that ES is still running in the background. I've never tried omxplayer before, so I'm not sure if this is the same behaviour as with the vendor driver.

I did read elsewhere that OpenVG doesn't work in fkms mode, meaning that it breaks subtitles in omxplayer, but I didn't test a video that has embedded subtitles, so I'm not sure if that's still the case.

The plain drm driver of retroarch doesn't work in fake kms mode. Here's the last lines of verbose log before it exits:

[INFO] DRM: Number of planes on FD 3 is 2
[INFO] DRM: CRTC index found 0 with ID 25
[INFO] DRM: plane with ID 23 is not an overlay. May be primary or cursor. Not usable.
[INFO] DRM: plane with ID 24 is not an overlay. May be primary or cursor. Not usable.
[INFO] DRM: couldn't find an usable overlay plane for current CRTC and framebuffer pixel formal.

Killing ES and manually launching retroarch with the same arguments doesn't help.

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 2, 2017

Another thing: if fake kms allows dispmanx and hardware acceleration without the vendor drivers, theoretically, Kodi may still be usable.

I can see that kodi's binary is linked against the brcmGLES and brcmEGL libraries, so I was going to try recompiling the current release against the mesa libraries, but the latest deb source is not available from the raspberrypi.org repository, unfortunately.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 2, 2017

Kodi 18 has a drm/kms implementation:
xbmc/xbmc#11955

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 2, 2017

I've seen it, but I'm talking about dispmanx. I recompiled retroarch with dispmanx support re-enabled and can confirm that the dispmanx driver does work in fkms mode (after changing the build configuration to not depend on the videocore driver).

This means that Kodi 17 might run OK in fkms mode via a dispmanx context if it's built against the mesa libraries, and of course, the SDL2 backend is still compiled with dispmanx support.

Edit:
In kms mode, retroarch with the dispmanx driver set runs but displays no video, just the same as omxplayer. So this essentially confirms that dispmanx works fine in fkms mode. I suspect that ES may be running in a dispmanx context when fkms is enabled due to omxplayer's overlay working, but I can't be certain due to the debug logging not giving any hints to the video mode.

I think we need to change our default assumption for this VC4 experiment, and build with dispmanx support intact. Some code changes may be necessary in projects to untangle dependencies, such as RetroArch's dispmanx configuration unnecessarily forcing the videocore driver to be built as well.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 2, 2017

I think i will add a new platform for fkms testing. This platform will install the following things:

  • SDL2 with dispmanx support but mesa gles libs. ES and mupen64plus will use this SDL2 package.
  • Our current reicast repo with dispmanx support. Replace vendor libs with mesa libs.
  • Retroarch with kms context for gl video driver and dispmanx video driver. lr-mupen64plus and lr-ppsspp look much better. kms should have less input lag.
@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 2, 2017

Does it need a separate platform? Something like this can be done:

if grep -q "^dtoverlay=vc4-fkms-v3d" /boot/config.txt; then
    __platform_flags+=" mesa kms dispmanx"
else if grep -q "^dtoverlay=vc4-kms-v3d" /boot/config.txt; then
    __platform_flags+=" mesa kms"
else
    __platform_flags+=" videocore dispmanx"
fi

export PKG_CONFIG_PATH="/opt/vc/lib/pkgconfig"

The pkgconfig files are not yet present in current firmwares, but will be useful for fkms, as dispmanx needs to build against bcm_host, vcos and vmcs_host.

Then comes the part of sending PRs to upstream repos with the general idea:

  • The existing RPI hacks need to start using the new vendor library names. This is not just because of stretch - it's necessary even for jessie, because there's no guarantee that the next jessie firmware will continue to offer the originally-named libs. However, the current hacks that detect files in /opt/vc are still useful due to the pkgconfig not yet being present in existing libraspberrypi-dev packages.
  • Given the previous point that some hacky detection is still needed in makefiles, we need ensure there's a way to override the hacks somehow. We can set a environment variable for the isPlatform = "mesa" case that will skip over the hacky code to use the brcmX libraries/includes.
  • Fix projects with existing dispmanx support to detangle from unnecessary linkage to vendor graphics drivers or libraries. RetroArch is all that comes to mind for the time being.

Of course we shouldn't send any upstream PRs yet in order not to step on Jools' toes, but it's going to need a little bit of coordination for upstream projects so that the mesa vs vendor libs can be selected during building.

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Sep 2, 2017

Doing something as @psyke83 says would work. However, it could fail on berryboot for example. Also if someone switches on the open source driver we might want to handle that (eg - store the "installed" state somewhere and put up a warning if switching).

I will enforce a recent libraspberrypi-dev package also, which will help with the upstream issue. I will likely do this before 4.3 (I am currently still building/testing stuff for the 4.3 release).

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 2, 2017

@joolswills,

Maybe this could be an opportunity to add some rudimentary version tracking to installed packages? You could add a "retropie.version" file to each build that includes the git revision (or tarball name if not a repository, etc) and dump the __platform_flags? The script could match against the currently-detected flags and trigger a warning/rebuild/redownload or whatever is appropriate.

@Darknior

This comment has been minimized.

Copy link

Darknior commented Sep 2, 2017

I like your idea @psyke83 ... i never know if i must update package or not, if i have the last version or not.
We must watch the git of each one to know if we must update or not.
Thanks for VC4 implementation project with OpenGL ... i love the idea :)

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 3, 2017

@joolswills,

For berryboot, the following would work IFF the /boot partition is mounted somewhere - and should also fix detection if booting from USB:

for i in $(ls /dev/mmc* /dev/sd*); do
  testconfig="$(df -P "$i"  | tail -1 | awk '{ print $NF}')/config.txt"
  [ -f $testconfig ] && configfile=$testconfig && break
done
@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 3, 2017

Before we think about implementation we should answer some questions. I would like to hear some second opinions:

  • Is there any benefit using mesa drivers?
    The GLES2 driver seems to have less glitches in GLideN64 and lr-ppsspp. Retroarch kms drm context is known for low input lag. The GLES2 implementation seems to be better. We can use GL 2.1 applications. New kernels and mesa releases will improve performance and compatibility.
  • is the mesa driver stable enough?
    I don't know.
  • does the mesa GLES2 driver perform better?
    Some retroarch shaders seem to run better. lr-mupen64plus seems to run much better (Goldeneye, CBFD, WaveRace). lr-ppsspp seems to run on par.
  • Does the mesa GL2.1 driver have any advantages?
    Not really tested. We don't know if this driver performs better. More retroarch shaders seem to run out of the box. GL only things should work. GlideN64 and lr-mupen64plus will not run because they need GL3.3. We can use lr-parallel or Rice/Glide instead.
  • Is it possible to mix dispmanx and mesa libs in an application.
    No tested. We know we can run dispmanx applications and mesa applications at the same time if fkms is enabled. We do not know if mesa driver needs a kms driver context. @psyke83 SDL2 was build without dispmanx support. ES should run with kms context if fkms is enabled.
  • Does Raspberry Pi 4 support vendor libs?
    We don't know but Eric Anholt is working on an open source VC5 driver for a new broadcom soc with gles3.1 support. https://anholt.github.io/twivc4/
  • Do we want kms support for all platforms or for rpi only?
    If we want kms support for all platforms there should be a generic solution. If we want to use fkms with dispmanx there will be a pi specific solution.
@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 3, 2017

Some thought on your questions:

  • Is there any benefit using mesa drivers?
    Yes, but I think we should look at vc4 support as an optional feature, not to become the default configuration. The Foundation wants to switch to this driver, so we are effectively helping to future-proof RetroPie and any related projects we send PRs to.
  • is the mesa driver stable enough?
    It seems quite stable, but I think you're asking the wrong question. The problem is that the mesa driver is not yet feature complete, specifically with regards to HW accelerated video decoding. Native KMS doesn't have any easy way of doing on-the-fly modesetting without an X server; I'm not aware of a way to change modes after boot without xrander? However, fkms seems to be a good compromise since we can continue using tvservice, etc.
  • does the mesa GLES2 driver perform better?
    I can echo your results. It is at least on par, I think. I'm certain that lr-parallel runs better with a wider range of working video render options beyond "rice".
  • Does the mesa GL2.1 driver have any advantages?
    Also haven't checked enough to comment, but it's good to open up our options.
  • Is it possible to mix dispmanx and mesa libs in an application.
    From: https://github.com/raspberrypi/linux/blob/a6d7c7353dfd938f8f5c6d6f33813f2c4b3ff7dc/arch/arm/boot/dts/overlays/README#L1553, it describes vc4-fkms-v3d as "Enable Eric Anholt's DRM VC4 V3D driver on top of the dispmanx display stack". The full KMS driver is not intended to ever support dispmanx. The end goal of the mesa driver is to move completely away from dispmanx etc., but that's realistic only when HW decoding support is implemented. Full KMS is not realistically useful for us yet.
  • Does Raspberry Pi 4 support vendor libs?
    Does it matter? anholt has repeatedly stated his aspiration for the Foundation to move away from the vendor libraries. We can assist with that by helping laying the groundwork in the upstream projects.
  • Do we want kms support for all platforms or for rpi only?
    We really need to maintain dispmanx support for fkms. Although the full kms mode is not yet useful for RPi, keeping the distinction separate and trying to make as much software as possible work in both normal kms or fkms will be a positive thing for non-Pi targets that are viable with KMS.
@rtissera

This comment has been minimized.

Copy link

rtissera commented Sep 3, 2017

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 3, 2017

@joolswills

Here's the fleshed out code to autodetect the correct platform flags: psyke83@b17fb8d

Tested and working as expected on a standard stretch install, though I'm not sure if the detection will help on berryboot. If the boot partition is not mounted anywhere, it won't detect correctly, and will fall back to the vendor flags.

I didn't get rid of the warning about the unsupported graphics stack, as this isn't intended to change the defaults away from the vendor libraries. The commit also adds the pkgconfig so that building will be easier in future firmwares.

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 4, 2017

@psyke83
I don't think mesa is working with dispmanx. I played around but had no success. fkms seems to allow kms on dispmanx or vice versa. This seems to happen completely transparent (firmware?). Retroarch runs with kms context ("system information") and SDL2 can be only used headless if kmsdrm build option is enabled. fkms seems to be the best solution to use tvservice/omxplayer and applications with kms/gl/gles2 support at the same time.

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Sep 4, 2017

Just FYI - I added some code to enforce 1.20170703-1 of libraspberrypi-dev/libraspberrypi-bin to ensure the libbrcm* libs are available. After 4.3 is out, we can update the various emulators to use the new names (and add optional support for using the open source driver)

8e28970

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 5, 2017

Reicast is running now. To get better performance display resolution must be lowered.

@NeonNixie

This comment has been minimized.

Copy link

NeonNixie commented Sep 5, 2017

@rekcah1986

This comment has been minimized.

Copy link

rekcah1986 commented Sep 13, 2017

@gizmo98
Could not successfully build mame4all - MAME emulator MAME4all-Pi
(/home/pi/RetroPie-Setup/tmp/build/mame4all/mame not found).

Could not successfully build mupen64plus - N64 emulator MUPEN64Plus
(mupen64plus-core/projects/unix/libmupen64plus.so.2.0.0 not found).

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Sep 13, 2017

@rekcah1986 Not sure why you are posting that here?

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Sep 17, 2017

@rekcah1986
I have no problem building mupen64plus. Mame4all is not tested.

@rekcah1986

This comment has been minimized.

Copy link

rekcah1986 commented Sep 19, 2017

@gizmo98
I couldn't install the "lr-mupen64plus" now.
This is the log:

...

FrameBuffer.cpp:(.text+0x1e8c): undefined reference to glDiscardFramebufferEXT' ./GLideN64/src/FrameBuffer.o: In function FrameBufferList::saveBuffer(unsigned int, unsigned short, unsigned short, unsigned short, unsigned short, bool)':
FrameBuffer.cpp:(.text+0x2a94): undefined reference to `glDiscardFramebufferEXT'
collect2: error: ld returned 1 exit status
Makefile:304: recipe for target 'mupen64plus_libretro.so' failed
make: *** [mupen64plus_libretro.so] Error 1
Removing additional swap
/home/pi/RetroPie-Setup
Could not successfully build lr-mupen64plus - N64 emu - Mupen64Plus + GLideN64 for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mupen64plus/mupen64plus_libretro.so not found).

@psyke83

This comment has been minimized.

Copy link
Member

psyke83 commented Sep 19, 2017

@rekcah1986

You didn't follow @gizmo98's instructions correctly. It's necessary to specify the platform via sudo __platform=rpi3-mesa ./retropie_setup.sh each time you launch the setup.

What's happening for you is that because you didn't specify the rpi3-mesa platform, it's attempting to build against the usual vendor libraries in /opt/vc - but on stretch, the vendor GLESv2 library was renamed to brcmGLESv2, and @gizmo98 didn't update the makefiles to account for the renamed libraries (as it's not his goal for testing).

It's probably not a good idea to pollute the issue tracker with support questions. The branch is just for testing and every time someone posts, everyone previously involved in the discussion gets a notification.

@gizmo98
I'm keeping an eye on the stretch packages for the next firmware update, as the next version will include the necessary pkgconfig which I suppose will make it a good milestone to start pushing PRs to enable stretch support to upstream projects. Since stretch will need the vendor libs renamed for upstream projects, it will probably be a good idea to coordinate a method to override these very hacks via a define, etc., in order to assist building against mesa for f/kms.

I'm curious if jessie will receive any firmware updates from this point on, too. If we send PRs that depend on the pkgconfig method of sourcing libraries, it could break jessie. The foundation have made things so messy by not organizing the pkgconfig much earlier on.

@rekcah1986

This comment has been minimized.

Copy link

rekcah1986 commented Sep 19, 2017

@psyke83 Yes, it works! Thank you very much.

@rekcah1986

This comment has been minimized.

Copy link

rekcah1986 commented Sep 19, 2017

Another error with "__platform=rpi3-mesa"

Makefile:71: recipe for target 'obj_mame_rpi/sound/fmopl.o' failed
make: *** [obj_mame_rpi/sound/fmopl.o] Error 1
make: *** Waiting for unfinished jobs....
src/sound/fm.cpp: In function ‘UINT8 YM2608Read(int, int)’:
src/sound/fm.cpp:2260:52: warning: array subscript is above array bounds [-Warray-bounds]
else ret = F2608->OPN.ST.status | (F2608->adpcm[6].flag ? 0x20 : 0);
~~~~~~~~~~~~~~^
/home/pi/RetroPie-Setup
Could not successfully build mame4all - MAME emulator MAME4All-Pi (/home/pi/RetroPie-Setup/tmp/build/mame4all/mame not found).

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Sep 19, 2017

The part you posted doesn't show the error. As mentioned - this ticket is the wrong place for stuff like this - please stop posting here. If you are unable to fix problems yourself, I recommend you wait until support is added.

@sigmaris

This comment has been minimized.

Copy link

sigmaris commented Jun 6, 2018

I've been hacking on the scripts a bit trying to build a RetroPie image for the Pi 2 / 3 using KMS and Mesa instead of dispmanx and Broadcom's GL (i.e. the full KMS driver implementation, using vc4-kms-v3d, not vc4-fkms-v3d).

I'm confused over the combination of __platform and __platform_flags that should be used to represent this type of configuration.

__platform __platform_flags
rpi2/rpi3 arm armv7 (or armv8) neon rpi gles mesa kms
rpi2-mesa/rpi3-mesa arm armv7 (or armv8) neon rpi gles
rpi2-mesa/rpi3-mesa arm armv7 (or armv8) neon rpi gles kms
rpi2-mesa/rpi3-mesa arm armv7 (or armv8) neon rpi gles mesa kms

basically, which combination above is the way to indicate we want to build stuff with KMS and Mesa support instead of videocore and dispmanx - do we add -mesa to the platform, or add mesa and kms to the platform flags, or possibly both?

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Jun 6, 2018

Well, the platform is unlikely to change, since we will handle adding the flags automatically based on the system, but the flags would probably need mesa / kms but since support isn't added yet etc, it's not really possible to answer - you are asking what flags to add for something that isnt implemented.

You can take a look at the changes gizmo did on his branch.

@joolswills

This comment has been minimized.

Copy link
Member

joolswills commented Jun 6, 2018

(or are you specifically asking about gizmo's repository ? in which case, he would be able to answer that, but nothing is implemented yet in our main code base).

@sigmaris

This comment has been minimized.

Copy link

sigmaris commented Jun 7, 2018

I've started with gizmo's branch and merged in more recent commits from this main repository, in https://github.com/sigmaris/RetroPie-Setup/tree/rpi-kms/

I guess I'm asking, if I was to continue work on this and go through all the main emulators making sure they compiled and worked OK, which platform/flags combination should I check in order to set compile flags specific to this configuration.

It sounds like the first combination, e.g. __platform=rpi2, __platform_flags+=(mesa kms) is the way to go.

@riverscn

This comment has been minimized.

Copy link

riverscn commented Oct 11, 2018

will kms vc4 merge to the main repository?

@gizmo98

This comment has been minimized.

Copy link
Member Author

gizmo98 commented Oct 11, 2018

I'm not up to date but i think it will be added to the main repo if vc4 driver is as good as the current binary blob and/or if the foundation switches to vc4/kms (could be if a raspberry pi 4 will be released with vc5/vc6 mesa driver ;-) ) anytime in the future.

There is a foundation thread about vc4 driver update plan:
https://www.raspberrypi.org/forums/viewtopic.php?t=216804

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.