Emulator Issues #483
closedCheckboxes for JIT/other optimizations
0%
Description
It would be nice for users and developers to enable/disable various safe
and unsafe optimizations with a nice UI and without recompiling.
Many examples can be found:
-Fast memory
-Block linking (jo.enableBlocklink = false, see issue 427)
and more...
This could be added to a tab in the settings menu called "Optimizations"
and Optimize Quantizers can also move there.
This is also an important factor on how "unsafe" these optimizations really
are. :)
Please do something.
Updated by XTra.KrazzY almost 16 years ago
Issue 427 has been merged into this issue.
Updated by XTra.KrazzY almost 16 years ago
Also, a drop-down box for compiler can replace the old Interpreter/JIT. This way we
can easily call the JIT WIP class in a different name (i.e. class JitIR64) and add a
combobox item to it for smooth testing/merging.
Updated by tinctorius almost 16 years ago
Or make the core a plugin as well (JIT, JIT WIP, Interpreter) ;)
Updated by maroofsbp almost 16 years ago
yes in this way many game crashes problems will be solved
Updated by Anonymous almost 16 years ago
I can see this being handy in the debugger. I don't think a plethora of options
should be in the main app...it should just use what works. If block linking is
causing problems, fix it or disable/remove till it's fixed.
Updated by slink_3_ almost 16 years ago
block linking is already disabled since r1596 because it is said to be an "unsafe"
optimization, but since then, some specific games run way slower than before (..)
Updated by nakeee almost 16 years ago
making it a plugin sounds like an overkill if some specific option is important I
think it might be nice to have it as an optional method.
But do be aware that every option you add will add various ifs to the code
and that in turn will make things slower...
Updated by montecrudo almost 16 years ago
What about adding those options to an specific game and not all? Like, for example,
adding the speed hack for Pokemon Colosseum and Smash Bros Melee only. So the games
having issues with the speed hack won't be affected.
Updated by XTra.KrazzY almost 16 years ago
Adding the hacks is not adding more branches... They already exist but have to be
changed at compile time. What's more, people don't know they can activate these hacks.
I never said that the core is a plugin, it is a serious part of the emulator and its
core element (duh)... But: Interpreters are already divided into classes
(Interpreter, Jit64 and the Jit64 IR copy), just adding a combo-box to choose which
one to use (again, not during the run of a game but in the configuration menu) and it
will work smoothly. All it takes is to change the IR JIT class name and add the
corresponding drop down.
As for the hacks, it should be done by someone who knows all of them, safe and
unsafe. Those need to be enumerated for some other person to GUI code them. That's
why I CCed the specific people who might know the intricates of the JIT and others
who know how to code WX UI.
Team work, people! The building blocks of success are the developers and teamwork is
the cement!
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
Updated by magumagu9 almost 16 years ago
I generally don't think adding more options is appropriate... instead of adding more options to the GUI,
we should really be fixing known-unsafe optimizations to be safe. If there are hugely beneficial
optimizations which are difficult to make safe, we can add them to the Core configuration, like the
current "Optimize Quantizers" option.
If we want to make it easier for non-developers to try and isolate JIT bugs, we can extend the "CPU
mode" menu in the debugger to expose more options.
Updated by XTra.KrazzY almost 16 years ago
Sure, that's an option as well. Though if you want to test for speed you might not
want to run the debugger, is there a slowdown there?
Updated by magumagu9 almost 16 years ago
Having the debugger running in and of itself shouldn't be a slowdown as far as I
know. If you can see any difference, please file a bug; we want the debugger to be
usable without worrying about slowdowns.
Updated by montecrudo almost 16 years ago
Uhm, I've tried a debug version of Dolphin myself and it runs horribly slow. The JIT
operates no more than 130Mhz and sometimes it can bring 4 fps ingame.
Updated by Anonymous almost 16 years ago
If you don't NEED debug build, use debugfast
Updated by XTra.KrazzY almost 16 years ago
Montecrudo: I think you mean running the debugger, which is also compiled with
release. Just run "dolphin.exe /d" or "dolphin.exe -d".
Updated by omegadox almost 16 years ago
Now this is something to try in Playground :P
Updated by marcus over 15 years ago
You should have a 'reset to defaults' button if there are more than a few options.
Updated by XTra.KrazzY over 15 years ago
Hmm, I should be getting on this one later on...
Updated by XTra.KrazzY almost 15 years ago
- Status changed from New to Won't fix