01-21-2013, 08:34 PM
It's coming
[Edit] I'm modifying this post to add my hardware post in to it so it doesn't get lost [/Edit]
![[Image: v0-m]](http://gdurl.com/v0-m)
[Edit] I'm modifying this post to add my hardware post in to it so it doesn't get lost [/Edit]
Quote: Let's talk about hardware first.Here's the Youtube video as well
Right now the CPU doesn't matter. I'd recommend a Qualcomm snapdragon S4(krait) at 1.7Ghz or higher, or a Cortex-A15 once they are out in cell phones.
Qualcomm's new Krait 800 series CPU that has been announced should be the highest performing CPU on the market when it comes out.
My reason for CPU not being the matter right now is because the CPU isn't the bottleneck at the moment.
Right now I can only run the VideoSoftware backend, which as everyone knows, gets terrible performance no matter what you do.
The reasoning of this is because the GPUs available on the market needed to run the OpenGL plugin are currently lacking driver support.
Absolute /minimum/ GPU requirements for the OpenGL plugin.Firstly, let me talk about the Adreno 320 and the Mali-T604. Both of these bits of hardware support OpenGL ES 3 in /hardware/ only.
- Adreno 320 (Still needs OpenGL ES 3 drivers)
- Mali-T604 (Still needs OpenGL ES 3 drivers)
- Some versions of the PowerVR 540/543/544/554 (GLES2 only)
Both Imagination Qualcomm(Adreno) and ARM(Mali) have yet to release information on when this hardware will get OpenGL ES 3 drivers available to consumers.
That being said, there is a performance warning I need to give on this new high end mobile GPUs. BOTH of these mobile GPUs are entry level GPUs that were only used to show off the new hardware's potential. Both Imagination Qualcomm and ARM don't like the performance of these new chips, which is why ARM has been working on getting hardware vendors off the T604 and onto the T624 as soon as possible.
Qualcomm's announcement of the Krait 800 series SoCs has brought about information on the Adreno 330 which offers 2x compute performance, and 50% overall performance improvement over the Adreno 320. This SoC should be out in consumer hardware sometime this summer.
Those two SoCs are the bare /minimum/ GPUs you'll need to run with any speed even in BAM3K just because they'll support OpenGL ES 3 in the future.
But the outlier is is the PowerVR series that is available is a multitude of products. The PowerVR series that ISN'T in the Apple products, supports two OpenGL ES 2 extensions that no other SoC supports both of. That is GL_OES_Vertex_Array_Object and GL_IMG_uniform_buffer_object.
Now saying that, there is a warning on this SoC. These buggers WILL be slower than molasses on a cold winter day, and that's if I can even get the support for them crammed in to the OpenGL video backend.
Outlook on PVR5 now: No.
Now the recommended Mobile GPUs for mobile hardwareAlright, the Adreno 330 is 2x performance boost over the 320 variant which still puts its specs under the Nvidia Geforce 310 in terms of processing power. Same stipulations that it needs driver support.
- Adreno 330
- Mali-T658/T678
- Tegra 4
The Mali-T658 is supposed to be quite a good upgrade at 2x the performance of the T624, which is 2x the T604. So a 4x performance boost over the T604. This still puts it under the raw power of the Geforce 315 class card, but over the Geforce 310. The only SoC that is rumoured to have the T658 is the Exynos 5450 Quad core platform which hasn't even been publicly announced and /may/ have been dropped in favour of their "octa" campaign.
Let's branch a second here since I've actually been asked about Samsung's octa SoC.
Samsung's Octa SoC, is a "octo" or eight core SoC. There is a catch here that most people don't get; This is part of ARM's BIG.little endeavor.
What you basically get is four high performance Cortex-A15 cores for when you need to power through things, and 4 low power cores(Cortex-A7) that run low power applications. The SoC can mix and match these CPUs however it wants, but there is one limitation. You can only be using four cores at a time. So either four A15s, or Four A7s, or a mix like 2 A15s and 2 A7s.
Now this is a great idea, it means you get a powerful phone that if you aren't doing anything crazy on it, it'll idle for a long time. But that doesn't help us here. We need 2-3 of the fastest performing CPU cores we can get, and since Samsung's Octa SoC is using a PVR544MP3, I may not be able to support it.
Now then, to the last item on the list of the recommended GPUs. The Tegra 4.
This is the mobile GPU that I am most hopeful for getting halfway decent speeds under our OpenGL plugin.
And by halfway decent speeds, I'm not saying it'll run through Twilight Princesses Hyrule fields at any great speed.
This new GPU from Nvidia is rumoured to be a stripped down version of their Keplar class cards which they use in their latest desktop GPUs. If this is true, that should mean that this GPU will outclass every other mobile GPU on the market. [Edit] I was wrong about it being Keplar based, Anandtech had a good article on this. The Tegra 4 /may/ still be the best mobile GPU once it gets to market.[/Edit] Now there haven't been any performance benchmarks on the GPU yet, but Nvidia did show off that its quad-core Cortex-A15s in it can beat the dual-core Cortex-A15s in the Nexus 10 tablet. Whoop de do, Quad A15 versus Dual A15, of course the quad is going to win.
I'm still hopeful that the GPU will kick enough ass to make OpenGL quick enough for a small percentage of games to run near full speed. BAM3K, Crazy Taxi, and maybe stretching it a bit, Super Smash Brothers Melee. Okay, they'll be a lot of issues with that last one not reaching full speed.
Anyway. That's the hardware out of the way, let's go a bit over the software quickly.
Dolphin's OpenGL plugin in the master branch is in a abysmal state. It uses deprecated OpenGL calls /all/ over the place which isn't compatible with OpenGL ES in the slightest.
Good thing though, even though it is using long deprecated OpenGL functions, it is actually pretty darn quick. The drivers, especially Nvidia, are able to optimize our code paths relatively well and actually get some good speed out of it.
Although this won't help mobile hardware where we just can't use these deprecated functions at all.
Now, there has been the GLSL branch which has been in development for nearly two years now, I had started this branch quite a while ago and it still isn't completed. It is /nearly/ completed, we are just having a few performance regressions and OSX support is being a PITA.
In the past few months, I've been getting a LOT of help from degasus. He is someone that actually knows how OpenGL works while I'm one that just smacks it with a hammer until it does what I want. He has been the moving force in getting GLSL finally in to a working shape by fixing most rendering issues and removing nearly all the deprecated OpenGL functions out of the code. Kudos to him for really really helping out in that department.
Now the CPU core.
I've been working on the ARM JIT for probably around six-eight months now. I have a bunch of integer PowerPC instructions emulated, all the branching, and a few Loadstore instructions implemented, even with Fastmem.
Right now, if the game touches only Integer paths like BAM3K, the CPU core runs quite quickly, which is why the Melee intro movie runs so quickly in my video I posted. I implemented about 75% of the instructions it uses for playing that video.
What I am currently working on for the JIT core is floating point instructions. This requires me to implement code so I can take advantage of ARM floating point hardware, AKA VFPv3/VFPv4/NEON. I've only just begun this work so it is going to take a few weeks until it gets anywhere near a working state.
I'm starting work on these since once a 3D game starts running, like the Crazy Taxi intro in the game, FPU instructions take up around 85% of the CPU time since I don't have ANY emulated in my CPU core atm.
Also ector wants the ARM FPU work since he uses my ARM code for his PSP emulator, ppsspp.
Any way, work is progressing at a slow but steady pace, I hope to have a video up in a week or two showing off the code running on my HTC Droid DNA, but I can't make any promises at this point.
