We uploaded the wrong data before. So the offset on the host GPU pointer may work for the first vertices, the last ones run out bounds.
Let's just offset the upload instead.
MSVC 19.11 (A.K.A. VS 15.3)'s C++ standard library implements P0154R1
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0154r1.html)
which defines two new constants within the <new> header, std::hardware_destructive_interference_size
and std::hardware_constructive_interference_size.
std::hardware_destructive_interference_size defines the minimum
recommended offset between two concurrently-accessed objects to avoid
performance degradation due to contention introduced by the
implementation (with the lower-bound being at least alignof(max_align_t)).
In other words, the minimum offset between objects necessary to avoid
false-sharing.
std::hardware_constructive_interference_size on the other hand defines
the maximum recommended size of contiguous memory occupied by two
objects accessed wth temporal locality by concurrent threads (also
defined to be at least alignof(max_align_t)). In other words the maximum
size to promote true-sharing.
So we can simply use this facility to determine the ideal alignment
size. Unfortunately, only MSVC supports this right now, so we need to
enclose it within an ifdef for the time being.
* Fix bug where default username value for yuzu_cmd create an userprofile with uninitialize data as username
* Fix format
* Apply code review changes
* Remove nullptr check
This can just be a regular function, getting rid of the need to also
explicitly undef the define at the end of the file. Given FuncReturn()
was already converted into a function, it's #undef can also be removed.
Previously the second half of the value being written would overwrite
the first half. Thankfully this wasn't a bug that was being encountered,
as the function is currently unused.
This modifies the CPU interface to more accurately match an
AArch64-supporting CPU as opposed to an ARM11 one. Two of the methods
don't even make sense to keep around for this interface, as Adv Simd is
used, rather than the VFP in the primary execution state. This is
essentially a modernization change that should have occurred from the
get-go.
The kernel does the equivalent of the following check before proceeding:
if (address + 0x8000000000 < 0x7FFFE00000) {
return ERR_INVALID_MEMORY_STATE;
}
which is essentially what our IsKernelVirtualAddress() function does. So
we should also be checking for this.
The kernel also checks if the given input addresses are 4-byte aligned,
however our Mutex::TryAcquire() and Mutex::Release() functions already
handle this, so we don't need to add code for this case.
Avoids including unnecessary headers within the audio_renderer.h header,
lessening the likelihood of needing to rebuild source files including
this header if they ever change.
Given std::vector allows forward declaring contained types, we can move
VoiceState to the cpp file and hide the implementation entirely.
We pass a hint to the QPainter instance that we want anti-aliasing on
the compatibility icons, which prevents the circles from looking fairly
jagged, and actually makes them look circular.
Courtesy of @ogniK5377.
This also moves them into the cpp file and limits the visibility to
where they're directly used. It also gets rid of unused or duplicate
error codes.
The kernel caps the size limit of shared memory to 8589930496 bytes (or
(1GB - 512 bytes) * 8), so approximately 8GB, where every GB has a 512
byte sector taken off of it.
It also ensures the shared memory is created with either read or
read/write permissions for both permission types passed in, allowing the
remote permissions to also be set as "don't care".
Part of the checking done by the kernel is to check if the given
address and size are 4KB aligned, as well as checking if the size isn't
zero. It also only allows mapping shared memory as readable or
read/write, but nothing else, and so we shouldn't allow mapping as
anything else either.
Previously, these were sitting outside of the Kernel namespace, which
doesn't really make sense, given they're related to the Thread class
which is within the Kernel namespace.
There were a few places where nested namespace specifiers weren't being
used where they could be within the service code. This amends that to
make the namespacing a tiny bit more compact.
While unlikely, it does avoid constructing a std::string and
unnecessarily calling into the memory code if a game or executable
decides to be really silly about their logging.
Given these are shown to the user, they should be translatable.
While we're at it, also set up the dialog to automatically retranslate
the dialog along with the combo boxes if it receives a LanguageChange
event.
Keeps the individual initialization of the combo boxes logically separate.
We also shouldn't be dumping this sort of thing in the constructor
directly.
"value" is already a used variable name within the outermost ranged-for
loop, so this variable was shadowing the outer one. This isn't a bug,
but it will get rid of a -Wshadow warning.
It allows us to use texture views and it reduces the overhead within the GPU driver.
But it disallows us to reallocate the texture, but we don't do so anyways.
In the end, it is the new way to allocate textures, so there is no need to use the old way.
This places the font data within cpp files, which mitigates the
possibility of the font data being duplicated within the binary if it's
referred to in more than one translation unit in the future. It also
stores the data within a std::array, which is more flexible when it
comes to operating with the standard library.
Furthermore, it makes the data arrays const. This is what we want, as it
allows the compiler to store the data within the read-only segment. As
it is, having several large sections of mutable data like this just
leaves spots in memory that we can accidentally write to (via accidental
overruns, what have you) and actually have it work. This ensures the
font data remains the same no matter what.
When a destructor isn't defaulted into a cpp file, it can cause the use
of forward declarations to seemingly fail to compile for non-obvious
reasons. It also allows inlining of the construction/destruction logic
all over the place where a constructor or destructor is invoked, which
can lead to code bloat. This isn't so much a worry here, given the
services won't be created and destroyed frequently.
The cause of the above mentioned non-obvious errors can be demonstrated
as follows:
------- Demonstrative example, if you know how the described error happens, skip forwards -------
Assume we have the following in the header, which we'll call "thing.h":
\#include <memory>
// Forward declaration. For example purposes, assume the definition
// of Object is in some header named "object.h"
class Object;
class Thing {
public:
// assume no constructors or destructors are specified here,
// or the constructors/destructors are defined as:
//
// Thing() = default;
// ~Thing() = default;
//
// ... Some interface member functions would be defined here
private:
std::shared_ptr<Object> obj;
};
If this header is included in a cpp file, (which we'll call "main.cpp"),
this will result in a compilation error, because even though no
destructor is specified, the destructor will still need to be generated by
the compiler because std::shared_ptr's destructor is *not* trivial (in
other words, it does something other than nothing), as std::shared_ptr's
destructor needs to do two things:
1. Decrement the shared reference count of the object being pointed to,
and if the reference count decrements to zero,
2. Free the Object instance's memory (aka deallocate the memory it's
pointing to).
And so the compiler generates the code for the destructor doing this inside main.cpp.
Now, keep in mind, the Object forward declaration is not a complete type. All it
does is tell the compiler "a type named Object exists" and allows us to
use the name in certain situations to avoid a header dependency. So the
compiler needs to generate destruction code for Object, but the compiler
doesn't know *how* to destruct it. A forward declaration doesn't tell
the compiler anything about Object's constructor or destructor. So, the
compiler will issue an error in this case because it's undefined
behavior to try and deallocate (or construct) an incomplete type and
std::shared_ptr and std::unique_ptr make sure this isn't the case
internally.
Now, if we had defaulted the destructor in "thing.cpp", where we also
include "object.h", this would never be an issue, as the destructor
would only have its code generated in one place, and it would be in a
place where the full class definition of Object would be visible to the
compiler.
---------------------- End example ----------------------------
Given these service classes are more than certainly going to change in
the future, this defaults the constructors and destructors into the
relevant cpp files to make the construction and destruction of all of
the services consistent and unlikely to run into cases where forward
declarations are indirectly causing compilation errors. It also has the
plus of avoiding the need to rebuild several services if destruction
logic changes, since it would only be necessary to recompile the single
cpp file.
* Joystick hotplug support (#4141)
* use SDL_PollEvent instead of SDL_JoystickUpdate
Register hot plugged controller by GUID if they were configured in a previous session
* Move SDL_PollEvent into its own thread
* Don't store SDLJoystick pointer in Input Device; Get pointer on each GetStatus call
* Fix that joystick_list gets cleared after SDL_Quit
* Add VirtualJoystick for InputDevices thats never nullptr
* fixup! Add VirtualJoystick for InputDevices thats never nullptr
* fixup! fixup! Add VirtualJoystick for InputDevices thats never nullptr
* Remove SDL_GameController, make SDL_Joystick* unique_ptr
* fixup! Remove SDL_GameController, make SDL_Joystick* unique_ptr
* Adressed feedback; fixed handling of same guid reconnects
* fixup! Adressed feedback; fixed handling of same guid reconnects
* merge the two joystick_lists into one
* make SDLJoystick a member of VirtualJoystick
* fixup! make SDLJoystick a member of VirtualJoystick
* fixup! make SDLJoystick a member of VirtualJoystick
* fixup! fixup! make SDLJoystick a member of VirtualJoystick
* SDLJoystick: Addressed review comments
* Address one missed review comment
This virtual function is called in a very hot spot, and it does nothing.
If this kind of feature is required, please be more specific and add callbacks
in the switch statement within Maxwell3D::WriteReg. There is no point in having
another switch statement within the rasterizer.
Lets us keep the generic portions of the compatibility list code
together, and allows us to introduce a type alias that makes it so we
don't need to type out a very long type declaration anymore, making the
immediate readability of some code better.
- Fixed all warnings, for renderer_opengl items, which were indicating a
possible incorrect behavior from integral promotion rules and types
larger than those in which arithmetic is typically performed.
- Added const for variables where possible and meaningful.
- Added constexpr where possible.
When not set, this tells the GPU to only use the X size when performing a DMA copy.
This is only implemented for linear->linear and tiled->tiled copies. Conversion copies still retain the assert.
This bit is unset by some games for various purposes, and by nouveau when copying the vertex buffers.
* video_core: Arithmetic overflow fix for gl_rasterizer
- Fixed warnings, which were indicating incorrect behavior from integral
promotion rules and types larger than those in which arithmetic is
typically performed.
- Added const for variables where possible and meaningful.
* Changed the casts from C to C++ style
Changed the C-style casts to C++ casts as proposed.
Took also care about signed / unsigned behaviour.
This has gotten sufficiently large enough to warrant moving it to its
own source files. Especially given it dumps the file_sys headers around
code that doesn't use it for the most part.
This'll also make it easier to introduce a type alias for the
compatibility list, so a large unordered_map type declaration doesn't
need to be specified all the time (we don't want to propagate the
game_list_p.h include via the main game_list.h header).
Given we now have the kernel as a class, it doesn't make sense to keep
the current process pointer within the System class, as processes are
related to the kernel.
This also gets rid of a subtle case where memory wouldn't be freed on
core shutdown, as the current_process pointer would never be reset,
causing the pointed to contents to continue to live.
