-
Notifications
You must be signed in to change notification settings - Fork 53
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
[rbp] [retroplayer] Add zero copy mmal support to retroplayer #62
Conversation
Probably not working, but it does compile. I'm not currently able to build the emulator add-ons - getting "bnes needs RPi build command in CMakeLists.txt!" |
I'm not sure why this worked before but not now, you can see the error msg is here and results from the "rbpi" platform not having a build command. If it worked before, it was probably because it was using the "linux" core system name. Which of these is it set to currently? |
I'm not 100% sure if I used the emulators I built last time, or the ones from LE repo.
|
Hm, I've encountered this problem before. I applied adfc09f, but I can't remember if this fixed the problem or not. |
Is it fine if I merge this now? I'll keep the commits separate and if there's any changes you can just send another PR to this branch. |
A mmal commit has just gone into master which has a minor conflict with this. If you update retroplayer-17alpha2 branch I can rebase this commit now, |
which PR? I'll cherry pick it and you can rebase on that, then next time I rebase on a release (alpha 3) this will apply cleanly |
(although you might need xbmc#10144 to apply that one...) |
092261f
to
5cbfc1b
Compare
I cherry-picked that PR (and 4 others it required), but this PR still applies cleanly. Are these PRs needed? |
I had a conflict here: 4828fc2#diff-c7916b114ea763a60c3ab748710a75d7R279 I am in the process of building with adfc09f present to see if that fixes my issue. With xbmc#10120 in place 18028ae can be dropped (although the next commit will need fixing up). |
I plan to rebase on 17 alpha 3 when it's released (around 1 August), do you just want to wait until then? |
5cbfc1b
to
f878af2
Compare
I've rebased. Hit a build error:
Any ideas? |
xbmc#9663 adds power off support to the Peripheral API. My alpha 2 branch is applied on top of this PR. it looks like you're trying to build against master's headers, try building against RetroPlayer's peripheral API. |
Are you just saying a need to do a clean build from this branch? I think the new commit have also broken something:
|
This looks correct, it references [CDVDFactoryCodec::CreateAudioCodec()](https://github.com/garbear/xbmc/blob/retroplayer-17alpha2/xbmc/cores/VideoPlayer/DVDCodecs/DVDFactoryCodec.h#L44]. The third parameter (bool) is optional, so calling with a CDVDStreamInfo& and a bool should compile. |
Previously we would always wait an extra vsync (even if one had been missed) in RenderUpdate. Now if a single vsync is missed, we won't wait.
Pool containing mmal buffers (e.g. decoded pictures) need to be attached to a mmal components port. Managing the lifespan of these is tricky, as renderer may consitue to display an image after the decoder has been closed and a new one opened. So create a class for handling this. The class creates and destroys the mmal component associated with the pool, and creates the mmal pool (which is just headers) as well as handling allocation of the gpu buffers. Each object from the pool includes a shared pointer to the pool class, ensuring the pool and mmal component are not destroyed until the last object is destroyed. The pool class is used by both MMAL hw decode and the FFMPEG zero copy decoders which avoids some special casing in the renderer. It will also handle the pool of deinterlaced frames later.
mmal callbacks all come from a common thread, so blocking in a callback is inefficient at best and can risk deadlocks. Creating a dedicated thread for processing mmal buffers (including the reconfiguration when formats change) avoids this.
I've rebased, but I'm struggling to run anything. Previously I was using this repo: I get as far as my code;
but get a segfault from the game itself (e.g. 2048 or MAME 2010). Is that repo up to date with this branch's API? |
ebde7c3
to
1c6c38e
Compare
f1da25a
to
3cb1e3d
Compare
Finally got retroplayer working again on Pi. I did find the second game I ran always crashes. Looks to be a bug here: But this PR should be okay for merging. |
Cheers. I'll fix the game.libretro issue |
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
Thanks to elpendor for RGB565 support, poisson for RAII improvements, ChrisMyhre for catching a compile error, notspiff for CMake fixes and popcornmix for Raspberry Pi support (#62). The RetroPlayer commit from the retroplayer-15.2 branch (20975ad) contains a TODO about `g_renderManager.IsStarted()` that may or may not apply still.
The crash should be fixed now. I'm uploading builds for the new branch based on 17alpha3 |
[addons] cleanup and improve changes
No description provided.