My change in 867cd99 caused farcode to fill up much more than before.
Most games still ran fine, but certain games would have multiple
cache clears per minute, on top of being overall slow.
Maybe there's something prettier we can do about this than just
allocating more RAM, but we have the resource budget for making
Dolphin use more RAM, so I consider increasing the size of the
cache to be a good solution at least for the time being.
At least for Prince of Persia: The Forgotten Sands, 48 MB isn't
enough to stop the cache clears, but 64 MB is. (I only played the
game for a few minutes when testing, though.)
This fixes the bad rendering on the first frame when using the software renderer: the software renderer's Z buffer started out at 0, but most games clear it to 0xffffff instead; this means that things don't render correctly except for in the regions where the screen was cleared by an EFB copy earlier in the frame.
The system menu does clear the RTC flags, but we currently aren't updating the cache file, and since we clear them the system menu doesn't know to update the cache either. This means that launching a game via the system menu, and then launching a game directly and exiting via HOME will result in the system menu using an outdated cache and displaying the old game. This causes it to fail to launch the game on the disc channel (since it doesn't match the cache), resulting in it resetting (though it will ignore the cache after resetting). Not clearing the cache avoids this issue.
Being able to preserve the address register is useful for the
next commit, and W0 is the address register used for loads. Saving
the address register used for stores, W1, was already supported.
If a host register has been newly allocated for the destination
guest register, and the load triggers an exception, we must make
sure to not write the old value in the host register into ppcState.
This commit achieves this by not marking the register as dirty
until after the load is done.
This does this following things:
- Default to the runtime automatic number of threads for pre-compiling shaders
- Adds a distinct automatic thread count computation for pre-compilation (which has less other things going on
and should scale better beyond 4 cores)
- Removes the unused logical_core_count field from the CPU detection
- Changes the semantics of num_cores from maximaum addressable number of cores to actually available CPU cores
(which is also how it was actually used)
- Updates the computation of the HTT flag now that AMD no longer lies about it for its Zen processors
- Background shader compilation is *not* enabled by default
This commit changes the default value of Fast Texture Sampling to true, and also moves the setting that controls it to the experimental section of the advanced tab. This is its own commit so that it can be easily reverted when we want to default to Manual Texture Sampling.
Co-authored-by: JosJuice <josjuice@gmail.com>
These messages apply to the User directory regardless of
whether it's global or local, so we shouldn't specify "global".
Also changing "directory" to "folder", just for consistency
with "GC folder" in the same sentence.
We implement this by first rounding to nearest integer using the current
rouding mode, then converting this value from floating point to an integral
value.
Prefer using eax to isolate the sign bit. This saves a byte when the
destination ends up as r8-15, because those require a REX prefix.
Before:
41 8B C5 mov eax,r13d
41 C1 ED 1F shr r13d,1Fh
44 03 E8 add r13d,eax
41 D1 FD sar r13d,1
After:
41 8B C5 mov eax,r13d
C1 E8 1F shr eax,1Fh
44 03 E8 add r13d,eax
41 D1 FD sar r13d,1
This moves the only direct call to zlib’s crc32() into its own
translation unit, but that operation is cold enough that this won’t
matter in the slightest. crc32_z() would be more appropriate, but
Android has an older zlib version…
The reload stub is at a fixed address (0x80001800) so its hook flag
should be HookFlag::Fixed.
Otherwise the hook is installed by HLE::PatchFixedFunctions but
immediately removed by HLE::PatchFunctions (which is called by
HLE::Reload right after PatchFixedFunctions).
Should fix https://bugs.dolphin-emu.org/issues/12716
While trying to work on adding audiodump support for CLI, I was alerted that it was important to first try moving the DSP configs to the new config before continuing, as that makes it substantially easier to write clean code to add such a feature.
This commit aims to allow for Dolphin to only rely on the new config for DSP-related settings.
This replaces the MAX_LOGLEVEL define with a constexpr variable
in order to fix self-comparison warnings in the logging macros
when compiling with Clang. (Without this change, the log level check
in the logging macros is expanded into something like this:
`if (LINFO <= LINFO)`, which triggers a tautological compare warning.)
GCC complains about float_emit being null when inlining
ByteswapAfterLoad into MMIOLoadToReg. ByteswapAfterLoad
does dereference float_emit, but only when passing FLAG_FLOAT,
which MMIOLoadToReg has an assert for and does not support.
Also cleaning up some unnecessarily specified namespaces while
I'm at it.
Reusing the slowmem handlers of existing blocks meshes badly
with reusing the empty space left when destroying blocks.
I don't think reusing slowmem handlers was much of a gain anyway.
This is done entirely through interpreter fallbacks. It would
probably be possible to implement this using host exception
handlers instead, but I think it would be a lot of complexity
for a rarely used feature, so let's not do it for now.
For performance reasons, there are two settings for this feature:
One setting which does enables just what True Crime: New York City
needs and one setting which enables it all. The latter makes
almost all float instructions fall back to the interpreter.
Instead of having a single GUI checkbox for "Always Hide Mouse Cursor",
I have instead opted to use radio buttons so the user can swap between
different states of mouse visibility. "Movement" is the default
behavior, "Never" will hide the mouse cursor the entire time the game is
running, and "Always" will keep the mouse cursor always visible.
There are two reasons for this.
1. Using Dolphin's logging system lets the user decide whether
the printout should go to the terminal, the GUI, or a file.
fmt::print always prints to stdout... unless you're on Android, in
which case it does nothing at all, because Android disables stdout.
2. The Windows version of Dolphin crashes when you use fmt::print.
Yes, really. The crash happens because a call to std::fprint in
fmt::v7::detail::fwrite_fully returns that less characters were
written than requested, which fmt handles by throwing an exception.
(As always, Dolphin does not use exception handling.)
I'm not sure why std::fprint is doing this, but since switching
away from using fmt::print is a good idea due to the previous point
anyway, I'd say it's best to just switch.
Previously, s_temp_input was being used for BOTH the savestate's and the movie's input printout in the panic alert.
This commit simply performs memcpy from the correct vector for the movInput printout.
Previously, only the number of total input polls would be shown in the window title when playing back a movie. This simply adds the VI / frame count total as well, which is a much more relevant number to look at while TASing.
Previously, using TAS Input to activate the digital L and R buttons would not show these inputs in the Input Display. This commit adds the digital L and R presses to the Input Display, and also displays just "L" or "R" if the analog is set to 255.
Now that we have enum helpers for inserting values into packets and have
migrated all other enumerations over, there's no need to keep this alias
around any longer.
Over time OnData() has become a huge function-long case statement that
attempts to manage numerous packet-related behaviors, which makes it a
little difficult to reliably ensure certain handling doesn't interfere
with another case's. It's also mildly annoying to navigate due to its
size.
To make it a little easier to read and find the specific behavior, we
can break the relevant pieces of code out into their own functions.
If W0 is locked when fpr.RW is called, the indirectly called
ConvertSingleToDoubleLower may need to emit a push+pop, so it's
better for fresx/frsqrtex to call RW before locking W0 than after.
This way the address check will take up less icache (since it's
only emitted once for each routine rather than once for each
psq_st instruction), and we also get address checking for psq_l.
Matches Jit64's approach.
The disadvantage: In the slowmem case, the routines have to
push *every* caller-saved register onto the stack, even though
most callers probably don't need it. But at long as the slowmem
case isn't hit frequently, this is fine.
In the case of the JitAsm routines, we can't actually use
backpatching. Still, I would like to gather all the load and
store instructions in one place to make future changes easier.
This is a proper fix for the issue that 3071a1d was a workaround for.
It wasn't some kind of bug in the register cache that had laid dormant,
it was a simple mistake made in b24b79e.
Fixes a regression from ecf86bb.
The GPR allocation_order is initialized with only 28 elements,
so the 29th element ends up getting zero initialized.
Very sneaky bug...
Previously in Read_U64 and Write_U64 the value that was read or written
would be truncated to a 32-bit value before being passed off to the
memcheck handler, which can result in incorrect values being logged out.
Lets us simplify SDRUpdated() a little bit.
This also fixes the layout of UReg_SDR1. Turns out this struct has been
incorrect (from a little-endian perspective) the entire time and went
unnoticed, since the union was never used.
These are trivial to resolve.
Converting the structure member into a u32 results in no increase in
structure size, as it's making use of the three extra padding bits in
the structure.
On a real Wii, these constants are normally written by the system menu
(maybe even as part of common SDK code?)
However, they're cleared by IOS whenever a PPC title is launched.
IOS memsets 0x0-0x3fff and then manually writes some constants
in low MEM1. PR #4723 added most of the writes in the 0x31xx region
but left out the four writes to the legacy constant region.
Previously Dolphin didn't actually clear 0-0x3fff so those constants
would stick around after a system menu execution.
011f7789e0 exposed those missing writes.
Prompted by https://dolphin.ci/#/builders/24/builds/985
A 1-character typo in a recent PR caused FifoCI builds to break
horribly and spew millions of panic alerts until buildbot crashed.
This PR adds a new config option -- defaulting to off -- that allows
Dolphin to abort early on when a panic alert occurs instead of
continuing forever.
Optimize division by a constant into multiplication. This method is
also used by GCC and LLVM.
We also add optimized paths for divisors 0, 1, and -1, because they
don't work using this method. They don't occur very often, but are
necessary for correctness.
Makes the enum strongly typed instead of interacting with a raw u32
value. While we're at it, we can add helpers to the NWC24Config to make
using code poke at the internals of the class a little bit less and also
make the querying a little nicer to read.
Currently we were using heap allocating maps that last for the entire
duration of the emulator running.
Given the size N of both of these maps are very small (< 20 elements),
we can just make use of an array of pairs and perform linear scans. This
is also fine, given this code isn't particularly "hot" either, so this
won't be run often.
These functions don't touch any class state, so they can be turned into
internal helper functions.
While we're at it, we can move the enumerations as well.
Although it's not clear what the xA and xB conditions are intended to do, the pattern indicates that xB is the regular version and xA is the inverted version, so for consistency, IsConditionB should be the main function.
Since the merge of b24b79e, we've gotten reports that the
following games are broken on JitArm64:
* Sonic Heroes
* The SpongeBob SquarePants Movie
* Astérix & Obélix XXL
* The Incredibles: Rise of the Underminer
Disabling the register cache avoids the issue, so the cause
of the bug might not actually have anything to do with the
newly implemented instructions. Nevertheless, I don't want
to ship a beta with this problem present, so I would like to
disable these instructions for the time being.
HandleFastmemFault works correctly when faults only happen in
expected locations, but it does some things that are rather
dangerous for faults in unexpected locations, like decrementing
an iterator without checking whether it's equal to begin.
This change cleans up the logic by making m_fault_to_handler's
key be the end of the fastmem region instead of the start.
JosJuice