search

RetroPie / RetroPie-Setup

Shell script to set up a Raspberry Pi/Odroid/PC with RetroArch emulator and various cores
Other
10.06k stars 1.39k forks source link

Add VC4 open source driver support #2093

Closed gizmo98 closed 5 years ago

gizmo98 commented 7 years ago

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: https://github.com/RetroPie/RetroPie-Setup/issues/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

dankcushions commented 7 years ago

cool!

DispManx not working

at least for retroarch, i think drm_gfx is supposed to replace this when using the new driver: https://github.com/libretro/RetroArch/pull/3181

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

psyke83 commented 7 years ago

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

joolswills commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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: https://github.com/raspberrypi/firmware/issues/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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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: https://github.com/RPi-Distro/firmware/commit/2440d3312fd900452b4e91b4a42325cbc75c1e2d)

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Kodi 18 has a drm/kms implementation: https://github.com/xbmc/xbmc/pull/11955

psyke83 commented 7 years ago

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 commented 7 years ago

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

psyke83 commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

psyke83 commented 7 years ago

Some thought on your questions:

rtissera commented 7 years ago

KMS support is the way to go for Rockchip based boards (Asus Tinker and Rock64) and possibly others.

Le 3 sept. 2017 11:25 AM, "psyke83" notifications@github.com a écrit :

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 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 software work 100% in both normal kms or fkms will be a positive thing for non-Pi targets that are viable with KMS.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RetroPie/RetroPie-Setup/issues/2093#issuecomment-326793961, or mute the thread https://github.com/notifications/unsubscribe-auth/AC3LBd14GBMTaqAfR1zqPLrJbwh3Pei4ks5senCKgaJpZM4O9Lgl .

psyke83 commented 7 years ago

@joolswills

Here's the fleshed out code to autodetect the correct platform flags: https://github.com/psyke83/RetroPie-Setup/commit/b17fb8d1c2446c8522f1a0c9458b13de99b2df92

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 commented 7 years ago

@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 commented 7 years ago

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)

8e2897037236835b75468307ea2dbdc1568ee05b

gizmo98 commented 7 years ago

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

NeonNixie commented 7 years ago

Thanks for the update!

On Sep 5, 2017 at 8:53 AM, <Stefan (mailto:notifications@github.com)> wrote:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (https://github.com/RetroPie/RetroPie-Setup/issues/2093#issuecomment-327165995), or mute the thread (https://github.com/notifications/unsubscribe-auth/AeKyVL7UP5ZFZAD_v-2MF-Nyy3krHljdks5sfURAgaJpZM4O9Lgl).

rekcah1986 commented 7 years ago

@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 commented 7 years ago

@rekcah1986 Not sure why you are posting that here?

gizmo98 commented 7 years ago

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

rekcah1986 commented 7 years ago

@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 functionFrameBufferList::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 commented 7 years ago

@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 commented 7 years ago

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

rekcah1986 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

(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 commented 6 years ago

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 commented 6 years ago

will kms vc4 merge to the main repository?