Android allows apps to use an arbitrary GPU driver? How does that work?
(I didn't even know Dolphin existed for Android, nothing on the web page points to that. Not that I've ever even used Dolphin, they just have so good release notes that I always check them)
Only the user mode part of the driver is replaced, the kernel interface is actually shared between the closed source and the open source driver. So it's just loaded like a DLL/.so and hooked up to the API.
This is only possible because of a very specific quirk of Linux: the interface between the kernel and user mode halves of the GPU driver is considered as sacrosanct as normal Linux syscalls[0]. If you want to get a graphics card driver in kernel you have to get your driver's UAPI approved by the kernel maintainers because it will be supported in Linux until the end of time.
No other operating system does it this way, nor will this work on Nvidia proprietary drivers. Everywhere else, the point of demarcation for graphics is OpenGL, DirectX, Metal, or Vulkan entrypoints in userspace. To be clear, there IS a UAPI here too - hardware isolation demands it - but it breaks constantly and nobody bats an eye. If you were willing to deal with that fragility, you could do the same trick on Windows or macOS.
[0] For those unaware, Linux has a very explicit policy of never breaking userspace. That means no ABI changes whatsoever.
> For those unaware, Linux has a very explicit policy of never breaking userspace
But has no qualm with constantly refactoring the kernel side of the coin for the most minor of reasons, which causes endless trouble when it comes to supporting out of tree drivers and is the true reason why Android will never be able to provide long term support. SOC manufacturers are not interested in the churn involved in updating their drivers to support the newer kernels that come with new android versions. Most often, it's because they want to keep their driver proprietary, but it is not the only reason, there is a cold hard truth about the nature of the market: new phones are released at a high cadence, while the process of mainlining a driver into upstream linux kernel is arduous, depending on the attitudes of kernel maintainers, truly painful, and no company out there could see any value in waiting for this process to end before releasing their hardware onto the market. Since they're already going to make it out of tree and release it as is, why would they bother? a year later, they'll repeat this process again, and again. Then Android updates, and the devices are obsoleted.
On the other hand, you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11. Windows doesn't constantly break your not-maintained-by-microsoft drivers with newer versions of their kernel.
For the part that most people care about (which is the userspace side, that comes from the Mesa Project) you can freely update it to whatever is the latest version without really having to care about the kernel side. The only point at which the kernel side of the GPU equation actually matters for Mesa is when new HW comes out.
>>you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11
MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
>MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
Not quite accurate, it depends on whether a new version of Windows has a significantly newer kernel.
Windows 2000 and Windows XP (and all its derivatives) share the NT5.x kernel, and thus drivers for any of them generally work in the others. Likewise Windows Vista/7/8/8.1 which all share the NT6.x kernel, and Windows 10 and 11 which share the NT10.0 kernel.
In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows. Because it was pretty normal to go from Windows 9x to XP (skipping 2k), then skip Vista and not upgrade until 7, then skip 8 and 8.1 and not upgrade until 10. The exceptions were mostly if you bought a new computer that had one of the more disappointing releases preinstalled, but in those cases driver breakage would have been much less of a concern anyways.
>In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.
I'll also add that it is very common for hardware manufacturers to just provide drivers for newer versions of Windows as they come out if necessary, with the hardware ending up supported across multiple versions of Windows.
It is very seldom when you actually come across hardware without drivers, unless the hardware is so old that the manufacturer isn't selling (and thus isn't supporting) it anymore.
To put a finer point on driver breakages... part of why Vista was so disastrously bad at launch was specifically because they'd drastically changed the DirectX kernel driver model to support DWM[0]. Nvidia in particular was responsible for a third of all Vista crashes, with another third being ATI (now AMD RTG). WDDM was a moving target right up until launch and it took about a year for Vista to actually be usable[1].
Yuzu has a similar feature on their android release. I bet that’s the big reason why these emulators are on android and not iOS, the graphics hardware on modern iPhones is certainly capable.
I'd guess missing the ability to sideload is also a huge factor. If Google doesn't allow Dolphin, they can use a different store or distribute the apk themselves. If Apple doesn't allow Dolphin, all the effort is in vain.
Yes, but iPhones are not uniformly jailbreakable, and restricting yourself to a niche like that makes it harder to get people in (as users or as developers). You've essentially moved from a popular platform (iOS) to a very niche one (jailbroken iOS).
Does this not require a Jailbreak anymore? I thought you needed a kernel exploit in order to enable JIT (without which Dolphin would be terribly slow).
The caveat for enabling JIT support is you have to “attach a debugger” first. AltServer automates this process…provided your iOS device can communicate with it when launching the app.
Game console emulators are surprisingly popular on Android. Even with a bluetooth controller, it seems like a terrible experience with a tiny screen that's even tinier if you're playing retro games with a 4:3 aspect ratio.
Android has quite a capable emulation ecosystem. There are emulators for most major platforms, and frontends like Daijishou make the experience very user friendly. There's a plethora of handheld devices from Anbernic, Retroid and others, with built-in controllers, so no latency from BT, or you can just get something like a Razer Kishi for a regular phone. Modern chipsets are very fast and efficient, screens are large and high resolution, battery life is excellent, etc.
We're really in the golden age of emulation on mobile devices.
IMO with the upscaling it's great for GB/GBA, and even PSP games. Even though the controls aren't "native", the experience overall is better because you avoid a lot of the monetization hell most Android games have become.
For anyone curious about the "Disney Trio of Destruction", that's Disney Infinity, Cars 2, and Toy Story 3 (all for the Wii) which have pretty subpar performance on Dolphin. https://dolphin-emu.org/blog/2022/05/17/dolphin-progress-rep... has some more info.
As eager as people are to get the Disney Trio to work, thank god it’s only forgettable shovelware and not something actually important like Mario Galaxy.
They might be shovelware, but they are still programs that are not being emulated correctly, showing that the emulator still isn't accurate enough. Who knows what else is missing then?
OP means if you know the emulation is a long ways from perfect, then even the games that are documented as running smoothly may have subtle gameplay differences below the surface.
Probably not things that most people could notice, but the trio is a nice benchmark to aim towards
There was this one game called True Crime: New York City which didn’t work on Dolphin because they used a bunch of non standard things also also because the game is so broken on native hardware that figuring out what is an issue with Dolphin and what is an issue with the game was an actual concern. https://www.pcgamesn.com/emulation/dolphin-games-true-crime-...
Kind of not surprised that True Crime NY is like that. It felt like a title that was a little strapped together and yet could push the hardware in unique ways at the same time.
"Accurate enough" isn't a boolean value. An emulator can emulate all games perfectly without being fully accurate, and it will be much much much faster than a fully accurate one.
It's accurate enough for most games, but not accurate enough for those specific three. But if getting them running doesn't give you anything besides getting them running, did you really improve your accuracy? Or just implement workarounds for those games?
You never know when a different game will be found to be broken by the changed behavior. At this point it's safe to say that pretty much all Wii games have been tested with Dolphin.
If changing the behaviour to make it more accurate breaks games then it was either implemented wrong or it exposed an existing bug. Either way, it’s a good test to find problems and make it even more accurate
It seems like you have this strange understanding that a perfect emulator works 100% like the original hardware (cycle accurate emulation). As I've already stated, you're not going to get a performant emulator by being 100% accurate, and making some games more accurate in a non-cycle-accurate way can result in bugs in other games.
In a perfect world with unlimited hardware resources you'd be right. But we don't live in that world and instead have to build non-cycle-accurate emulators, so you aren't.
Dolphin doesn’t aim for cycle accuracy, but it does aim to be as accurate as possible without making performance extremely bad. This philosophy has brought the emulator very far, as relying on game specific hacks means it will be forever limited to a small subset of the game library. The Dolphin devs always try to hardware-verify behaviours when possible. This extends to removing hacks that previously made games playable because it’s much better for code and emulation quality in the long term. If you disagree then you can make your own emulator I guess but it won’t get far
I don't know what you're trying to get at. For the original comment to make sense you'll have to show that:
- the "Disney Trio of Destruction" relies on behavior that isn't accurately emulated which can be emulated accurately without a big performance penalty
- the "Disney Trio of Destruction" is slow due to an inaccuracy which affects other games as well
- the "Disney Trio of Destruction" correct behavior doesn't negatively affect other game performance
Until you've shown this, you're essentially arguing for arguings sake - because I never said anything about "making my own emulator", I'm talking about the way Dolphin works.
But let's keep this spinning, and you build your own cycle-accurate version of Dolphin. Let's see how well that performs.
The “make your own emulator” was a somewhat snarky way to say that what you’re saying isn’t the same approach that the Dolphin devs take, and that their approach has taken them very far.
Yes, the things you said might not be met, which is why it isn’t already fixed. But you seem to be advocating for leaving things unfixed just because it’s unlikely that other games use them. My point is that attempting to fix inaccuracies even if they seem unimportant can often lead to other games being fixed and there have been many examples of this. If the bugs can only be fixed with cycle accurate emulation, then sure, you might have to leave them, but the attitude of “most games probably don’t rely on this so let’s not fix it” will only get you so far and to get the compatibility they have Dolphin had to take a more accurate approach. Of course, it makes sense to fix the things that more games use first
> The “make your own emulator” was a somewhat snarky way to say that what you’re saying isn’t the same approach that the Dolphin devs take, and that their approach has taken them very far.
You still seem to be under the impression that I'm somehow arguing for Dolphin to change their development model, or something like that. Why do you think so?
> Yes, the things you said might not be met, which is why it isn’t already fixed. But you seem to be advocating for leaving things unfixed just because it’s unlikely that other games use them.
I have not once done so. Literally, all I've argued for is "fixing the problems these games will have will not necessarily make the emulator better". You seem to acknowledge this given that you agree the three points I've mentioned aren't shown. So what exactly are you trying to argue about? Why are you trying to paint me like I'm telling anyone to change their development model?
You're jumping between acknowledging that Dolphin isn't cycle-accurate and not everything will be 100% accurate, and "But if they fix this it will improve other games!". No, it might, but it might also not. You have to show that it does if you want to argue against my point, because it literally is: it's not guaranteed to improve things beyond these three games".
Toy Story 3 on the Wii was an integral part of me bonding with my siblings as I was back from college on breaks. We really looked forward to it, and spent...hours, just noodling around in the game. It was so fun, and so ridiculously silly.
Mostly because of the hilarious local multiplayer (whether intentional or not -- but the shooter level _was_ pretty fantastic in a household not allowed to play online or non-cartoon shooter games)! Also, the very meme-able voice acting (Buzz Lightyear's iconic "hough-hoiuuuuuuuuuuuuooough" comes to mind. We would go around our day in the house and randomly do our best impression of it to make each other laugh. Sometimes it would start a bizarre stream of disconnected favorite pet quotes from the game between us. Near the peak of sibling bonding, almost as good as the moment one of us beat Super Monkey Ball 1's expert level 7 after midnight during a college break -- more than a cumulative decade of work off and on went into that. We absolutely involuntarily broke the quiet hours rule in the house when it happened. Top 5-10 moments of my life, I think.)
In any case, all that to say, this work is important as there are always people that find these things valuable. Everyone has a story, strange as it is. I'm really glad that attention is being brought to these titles, and once my siblings work through me being trans enough for us to be together, I think we might have a chance at sitting down and reliving some of the good old days together, ala emulator.
After about 20 minutes of searching, I found the voiceline in question at 7:46 at https://youtu.be/SeG5YYq8kQU . It's definitely not the same as the series of "two grunts in a row" that my siblings and I finally eventually settled on, but you can see why it would inspire such a silly practice.
Additionally, for more, um, very strong overacting that was the cause of lots of laughter in the house, please see 14:56.
You can see why we spent a near-majority of our time playing together as Buzz Lightyear, and finding the closest pit<->respawn point pairing so we could die as dramatically as possible as quickly as possible.
We spent many, many, many hours doing this. Some of the hardest times I've laughed in my life. Good times. Thanks to the above commenter who brought up this trio, you've brought a lot of nostalgia that has brightened a rather rocky week! <3 :)
55 comments
[ 4.2 ms ] story [ 33.7 ms ] thread(I didn't even know Dolphin existed for Android, nothing on the web page points to that. Not that I've ever even used Dolphin, they just have so good release notes that I always check them)
BTW, the NVIDIA opensource vulkan driver was dropped in mesa...
No other operating system does it this way, nor will this work on Nvidia proprietary drivers. Everywhere else, the point of demarcation for graphics is OpenGL, DirectX, Metal, or Vulkan entrypoints in userspace. To be clear, there IS a UAPI here too - hardware isolation demands it - but it breaks constantly and nobody bats an eye. If you were willing to deal with that fragility, you could do the same trick on Windows or macOS.
[0] For those unaware, Linux has a very explicit policy of never breaking userspace. That means no ABI changes whatsoever.
And when someone tries to do it - Linus gets very angry. https://lkml.org/lkml/2012/12/23/75
But has no qualm with constantly refactoring the kernel side of the coin for the most minor of reasons, which causes endless trouble when it comes to supporting out of tree drivers and is the true reason why Android will never be able to provide long term support. SOC manufacturers are not interested in the churn involved in updating their drivers to support the newer kernels that come with new android versions. Most often, it's because they want to keep their driver proprietary, but it is not the only reason, there is a cold hard truth about the nature of the market: new phones are released at a high cadence, while the process of mainlining a driver into upstream linux kernel is arduous, depending on the attitudes of kernel maintainers, truly painful, and no company out there could see any value in waiting for this process to end before releasing their hardware onto the market. Since they're already going to make it out of tree and release it as is, why would they bother? a year later, they'll repeat this process again, and again. Then Android updates, and the devices are obsoleted.
On the other hand, you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11. Windows doesn't constantly break your not-maintained-by-microsoft drivers with newer versions of their kernel.
>>you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11
MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
Not quite accurate, it depends on whether a new version of Windows has a significantly newer kernel.
Windows 2000 and Windows XP (and all its derivatives) share the NT5.x kernel, and thus drivers for any of them generally work in the others. Likewise Windows Vista/7/8/8.1 which all share the NT6.x kernel, and Windows 10 and 11 which share the NT10.0 kernel.
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.
It is very seldom when you actually come across hardware without drivers, unless the hardware is so old that the manufacturer isn't selling (and thus isn't supporting) it anymore.
[0] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
[1] A year afterwards of trying to convince people that Vista was good now (which it was), Microsoft threw up their hands and released Windows 7.
Walled gardens, eh?
With a jailbreaked iPhone device, you can possibly install Dolphin through a separate package manager (Cydia, Sileo, etc.)
The caveat for enabling JIT support is you have to “attach a debugger” first. AltServer automates this process…provided your iOS device can communicate with it when launching the app.
DolphinIOS exists though it’s a fork and requires somewhat unfriendly steps to get installed just due to iOS as a platform.
https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-ap...
I wish! Have you seen phones nowadays? They're bigger than tablets were in 2014!
We're really in the golden age of emulation on mobile devices.
Probably not things that most people could notice, but the trio is a nice benchmark to aim towards
It's accurate enough for most games, but not accurate enough for those specific three. But if getting them running doesn't give you anything besides getting them running, did you really improve your accuracy? Or just implement workarounds for those games?
In a perfect world with unlimited hardware resources you'd be right. But we don't live in that world and instead have to build non-cycle-accurate emulators, so you aren't.
- the "Disney Trio of Destruction" relies on behavior that isn't accurately emulated which can be emulated accurately without a big performance penalty
- the "Disney Trio of Destruction" is slow due to an inaccuracy which affects other games as well
- the "Disney Trio of Destruction" correct behavior doesn't negatively affect other game performance
Until you've shown this, you're essentially arguing for arguings sake - because I never said anything about "making my own emulator", I'm talking about the way Dolphin works.
But let's keep this spinning, and you build your own cycle-accurate version of Dolphin. Let's see how well that performs.
Yes, the things you said might not be met, which is why it isn’t already fixed. But you seem to be advocating for leaving things unfixed just because it’s unlikely that other games use them. My point is that attempting to fix inaccuracies even if they seem unimportant can often lead to other games being fixed and there have been many examples of this. If the bugs can only be fixed with cycle accurate emulation, then sure, you might have to leave them, but the attitude of “most games probably don’t rely on this so let’s not fix it” will only get you so far and to get the compatibility they have Dolphin had to take a more accurate approach. Of course, it makes sense to fix the things that more games use first
You still seem to be under the impression that I'm somehow arguing for Dolphin to change their development model, or something like that. Why do you think so?
> Yes, the things you said might not be met, which is why it isn’t already fixed. But you seem to be advocating for leaving things unfixed just because it’s unlikely that other games use them.
I have not once done so. Literally, all I've argued for is "fixing the problems these games will have will not necessarily make the emulator better". You seem to acknowledge this given that you agree the three points I've mentioned aren't shown. So what exactly are you trying to argue about? Why are you trying to paint me like I'm telling anyone to change their development model?
You're jumping between acknowledging that Dolphin isn't cycle-accurate and not everything will be 100% accurate, and "But if they fix this it will improve other games!". No, it might, but it might also not. You have to show that it does if you want to argue against my point, because it literally is: it's not guaranteed to improve things beyond these three games".
Mostly because of the hilarious local multiplayer (whether intentional or not -- but the shooter level _was_ pretty fantastic in a household not allowed to play online or non-cartoon shooter games)! Also, the very meme-able voice acting (Buzz Lightyear's iconic "hough-hoiuuuuuuuuuuuuooough" comes to mind. We would go around our day in the house and randomly do our best impression of it to make each other laugh. Sometimes it would start a bizarre stream of disconnected favorite pet quotes from the game between us. Near the peak of sibling bonding, almost as good as the moment one of us beat Super Monkey Ball 1's expert level 7 after midnight during a college break -- more than a cumulative decade of work off and on went into that. We absolutely involuntarily broke the quiet hours rule in the house when it happened. Top 5-10 moments of my life, I think.)
In any case, all that to say, this work is important as there are always people that find these things valuable. Everyone has a story, strange as it is. I'm really glad that attention is being brought to these titles, and once my siblings work through me being trans enough for us to be together, I think we might have a chance at sitting down and reliving some of the good old days together, ala emulator.
Fingers crossed! <3 :))))
Additionally, for more, um, very strong overacting that was the cause of lots of laughter in the house, please see 14:56.
You can see why we spent a near-majority of our time playing together as Buzz Lightyear, and finding the closest pit<->respawn point pairing so we could die as dramatically as possible as quickly as possible.
We spent many, many, many hours doing this. Some of the hardest times I've laughed in my life. Good times. Thanks to the above commenter who brought up this trio, you've brought a lot of nostalgia that has brightened a rather rocky week! <3 :)