Dolphin, the GameCube and Wii emulator - Forums

Sorry if this is a stupid question but is JITIL even still needed for... anything or anyone? Or does it not hinder any other development like e.g. DX9 did?

The progress reports have mentioned that comparing how it's broken vs how JIT's broken has helped isolate several bugs recently, so I wouldn't say it's as much of a hindrance as D3D9.

JITIL is useful in the sense that it could allow for a wide variety of optimizations to be done far more cleanly and easily than in the regular JIT, but it needs a lot of love to get up to the same standard. It's also not really designed ideally, given what we know now, I think: some devs have suggested we'd probably be better off bit by bit adding IL support to the current JIT instead of trying to resurrect JITIL.

To clarify/correct a few of these:

(01-02-2015, 11:08 PM)kirbypuff Wrote: [ -> ]* Anything you can do to optimize the GPU thread. The GPU thread is the main source of slowdown (bad performance) in Dolphin, especially when running at a high IR.

The CPU thread is already running very fast, because it's much easier to optimize. But optimizng the GPU thread is *HARD*. If you're looking for a challenge, this is the one for you.

Very few games are vertex loader or texture encoding bound now; probably at most a dozen or two (rough guess, I might be wrong). Most "GPU bound" games are actually bound by EFB transfers, whether pokes or EFB2RAM or similar, not the actual GPU thread. This is largely a matter of driver overhead, but certainly not an insurmountable problem: smarter EFB caching and other techniques could definitely be used to improve things.

(01-02-2015, 11:08 PM)kirbypuff Wrote: [ -> ]* Improve, optimize or rewrite the shader compiler. Dolphin's current real-time shader compiler and shader cache is very inefficient, leading to frequent pauses or massive stuttering. It has to be a better solution than TinoB's Async shader compiler and something that works well on Dual-Core CPUs.

The shader compiler is part of the GPU drivers and cannot be "rewritten" or optimized. Naturally there are some planned ways to try to improve compilation time stuttering (e.g. with generic ubershaders for not-yet-compiled TEV configurations) but I wouldn't recommend that for a new dev, since it's such a huge project and requires lots of knowledge of both the TEV pipeline and D3D/OGL.

If someone has a lot of knowledge about shader compilers they might be able to modify Dolphin's shaders to compile faster, but I don't know if that's really possible. Talking with an experienced shader compiler dev suggested it probably isn't possible to get a large improvement that way.

(01-02-2015, 11:08 PM)kirbypuff Wrote: [ -> ]* Fix the broken / garbled audio in ZFreeze titles with DSP HLE.

If by "zfreeze titles" you mean Rogue Squadron 2/3, this is because they use an older version of the AX library that is slightly different from the one HLE'd in Dolphin. Fixing this would require some reverse-engineering to identify the differences and implement them. Note it has no relation to zfreeze, just these two games IIRC.

(01-02-2015, 11:08 PM)kirbypuff Wrote: [ -> ]* Improve the current Stereoscopic 3D implementation to work with RealXFB as well.

* If possible, a way to use higher IRs than 1x with Real XFB.

This isn't really possible: RealXFB by definition can only work with 1x IR in such a way that it exactly matches the output of the Gamecube. But what can be done is enhancing Virtual XFB to support more uses of the XFB, so that fewer games actually need RealXFB. This is a subtle but important distinction.

Fiora improving virtual xfb is doable? It would be great if so, especially if it could cover the broken video cases with gamecube titles. After some conversations in the past with devs i gave up on asking about it, thought it is not doable.

As far as I know, yes: it's very primitive and only works with very specific uses of the XFB (beyond those that work with XFB off). It could probably be extended to support more, just like EFB2Texture could be improved to support more uses of the EFB.

(Someone correct me if I'm wrong on this) For example, both EFB2Tex and Virtual XFB (which is the equivalent of XFB2Tex) assume that the XFB/EFB will only be accessed in its entirety (as one single texture), not in part. But there's nothing saying we can't support partial usage of the XFB/EFB as a texture. I don't know if any game does this (you'd want to see what games actually do before trying to extend XFB2Tex/EFB2Tex), but this is just an example of something relatively straightforward that it doesn't support doing.

Basically "virtual XFB" is just a term for "anything that doesn't mean actually copying the XFB into RAM and downscaling it to 1x resolution like the Gamecube wants you to do", I think.

please direct people to this page for getting started with dolphin development on windows https://github.com/dolphin-emu/dolphin/wiki/Building-for-Windows

EDIT: Updated the original post.

@Fiora, JMC47 :

Fixed.

EFB2Subtex is the dreeeeeeeeam

[EDIT] Updated.

[EDIT #2] Updated again.

Check out the last one