I have been looking at other emulators who have implemented Vulkan or DX12 and they have seen performance increases. Would this be something that could improve overall perforrmance in Citra if it was implemented or is it just too new to provide any benefits?
We’re trying to develop our OpenGL core, we looked at a Vulkan renderer in the past, but we don’t want to split our development efforts currently.
Since Vulkan is similar to OpenGL, if someone wanted to work on it and have existing functionality still present, that would be possible right?
Sure! We welcome PR requests, but they’d preferably be tiny ones that are easy to review instead of a massive “Add Vulkan” PR.
You may want to check with the developers on IRC #citra-dev to make sure that’s something they want to focus on.
Yeah, I wouldn’t want to give them a massive PR to review. I’ve just started working with Vulkan and learning how it functions so I’m in no shape to implement it, but I would probably implement portions at a time as well as fix bugs with OpenGL in tandem. I’m still a bit of a newbie at C++ but I have some more courses to finish up and want to help contribute if I can.
Great news! Feel free to dive into our Discord and IRC, you’ll find more developers on IRC, probably.
If you plan to use existing vulkan tools, its going to be a licensing issue. They are APLv2 and while Citra claims to be GPLv2+ which would be compatible, its actually GPLv2 until every trace of the interpreter is gone from distribution. The interpreter is GPLv2 only meaning all of citra is GPLv2 and GPLv2 is not compatible with APLv2. Until dynarmic is 100% ready and we can create builds without the interpreter, theres going to be no vulkan.
it sucks that my integrated gpu does not support vulkan anyway
That makes sense. How far along is the dynarmic? I’ve been reading through GItHub, and kinda figuring things out as I go along.
quite a bit to go
So working on those instruction sets would be a good start to moving Citra into faster emulation and a much more stable environment?
Absolutely, yes. That would speed things along.
Any good place you would recommend I start researching and polishing up my knowledge on the instruction sets and things like that?
as flamesage mentioned try going on discord or IRC, someone might give you a step on the right track
You may want to reach out to a developer in IRC on #citra-dev
The bulk of the missing instructions are privileged instructions meaning 3ds games can’t use them since they run in user space only so we can get away with not emulating them. (Thats what Lioncache’s comment is saying)
so cpu emulation is not that far from being complete (for citra usage at least)
So for now, the remainder of instructions and stuff that needs to be done is overall optimization and the few instructions that are not privileged to be finished. Is that about right?
Except the corprocessor instructions which eat quite a chunk of time on some games. Merry already implemented them in dynarmic but in citra requires to implement the frontend for them
Anyways, the unimplemented instructions are not much of a concern since they are barely used by some games.
Dynarmic (Citra’s CPU JIT) itself isn’t really much of a problem right now.
About Vulkan and D3D 12. that’s like using a bazooka to kill flies. The performance concern is not what we use but the resources there are.
Citra has some bottlenecks right now:
- the vertex shader JIT produces very inefficient code. It’s on the list to fix after it has been correctly tested.
- all the vertex pipeline needs a rework and there’s a lot of accelerations that can be done for this like delegating the primitive assembler directly to OpenGL.
- texture caching can be improved a lot more.
- texture decoding is also a bottleneck for games like Super Smash Brothers.
- Currently citra is rendering 2 framebuffers (display images) at the sametime. This is because of how the 3DS make the 3D effect. There could be an option to “try” not to process the second image and just use the first. It would be kinda hacky though but it would reduce render times.
- Once the “emulated gpu” is emulated correctly, it can be decoupled and be run on another CPU Core.
In general, it’s a bunch of small bottlenecks that sum up but what we are currently using is more than enough. There’s no real need to make new backends
That’s a good point. I didn’t think of it that way. It still is a shame that you chose to no longer contribute. Your knowledge and skills are definitely something that was of great help to the project. I’ve noticed improvements in some of my games thanks to the work you had done. I didn’t think a new backend would fix everything. I just know there are some ways that Vulkan streamlines communication between the processor and the GPU which could be taken advantage of.