An HLE service function that wants to perform an async operation should put the caller guest thread to sleep using SleepClientThread, passing in a callback to execute when the thread is resumed.
SleepClientThread returns a ThreadContinuationToken that should be stored and used with ContinueClientThread to resume the guest thread when the host async operation completes.
This change makes for a clearer (less confusing) path of execution in the scheduler, now the code to execute when a thread awakes is closer to the code that puts the thread to sleep (WaitSynch1, WaitSynchN). It also allows us to implement the special wake up behavior of ReplyAndReceive without hacking up WaitObject::WakeupAllWaitingThreads.
If savestates are desired in the future, we can change this implementation to one similar to the CoreTiming event system, where we first register the callback functions at startup and assign their identifiers to the Thread callback variable instead of directly assigning a lambda to the wake up callback variable.
It is unlikely we will ever use this without first doing a Cast to a signed type.
Fixes 9 "unary minus operator applied to unsigned type, result still unsigned" warnings on MSVC2017.3
The loaders will now just create a Kernel::Process, construct it and return it to the caller, which is responsible for setting it as the current process and configuring the global page table.
Don't automatically assume that Thread::Create will only be called when the parent process is currently scheduled. This assumption will be broken when applets or system modules are loaded.
Only use the HLE interface if an HLE applet with the desired id was started.
This commit reorganizes the APT code surrounding parameter creation and delivery to make it easier to support LLE applets in the future.
As future work, the HLE applet interface can be reworked to utilize the same facilities as the LLE interface.
Not all physical regions need to be mapped into the address space of every process, for example, system modules do not have a VRAM mapping.
This fixes a crash when loading applets and system modules.
The current code inserts and deletes elements from the beginning of the audio buffer, which is very inefficient in an std::vector.
Profiling was done using VisualStudio2017's Performance Analyzer in Super Mario 3D Land.
Before this change: AudioInterp::Linear had 14.14% of the runtime (inclusive) and most of that time was spent in std::vector's insert implementation.
After this change: AudioInterp::Linear has 0.36% of the runtime (inclusive)
The loaders now register each loaded ROM with the SelfNCCH factory, which keeps the data around for the duration of the emulation session.
When opening the SelfNCCH archive, the factory queries the current program's programid and uses that as a key to the map that contains the NCCHData structure (RomFS, Icon, Banner, etc).
3dsx files do not have a programid and will use a default of 0 for this value, thus, only 1 3dsx file with RomFS is loadable at the same time.
* loader/ncch: split NCCH parsing into its own file
* loader/ncch: add support for loading update NCCHs from the SD card
* loader/ncch: fix formatting
* file_sys/ncch_container: Return a value for OpenFile
* loader/ncch: cleanup, always instantiate overlay_ncch to base_ncch
* file_sys/ncch_container: better encryption checks, allow non-app NCCHs to load properly and for the existence of NCCH structures to be checked
* file_sys/ncch_container: pass filepath as a const reference
* Services/UDS: Added a function to generate the EAPoL-Start packet body.
* Services/UDS: Added filter for beacons.
* Services/UDS: Lock a mutex when accessing connection_status from both the emulation and network thread.
* Services/UDS: Handle the Association Response frame and respond with the EAPoL-Start frame.
* fixup: make use of current_node, changed received_beacons into a list, mutex and assert corrections
* fixup: fix damn clang-format
As per 3dbrew:
"During Home Menu start-up it uses APT:PrepareToStartNewestHomeMenu. If that doesn't return an error(normally NS returns 0xC8A0CFFC for that), Home Menu starts a hardware reboot with APT:StartNewestHomeMenu etc. "
We need to know what is being run so we can set the APT parameter destination AppId correctly.
Delaying the preparation of the parameter until we know which AppId is running lets us support booting both the Home Menu and normal game Applications.
* WebService: Verify username and token; Log errors in PostJson
* Fixup: added docstrings to the functions
* Webservice: Added Icons to the verification, imrpved error detection in cpr, fixup nits
* fixup: fmt warning
PR #1461 introduced a regression where some games would change configuration
even while in the poorly named "drawing" mode, which broke the heuristic
citra was using to determine when to draw the batch. This change adds
back in a draw call for batching, and also adds in a draw call in
immediate mode each time it adds a triangle.
There is currently no stage tracking, a client is considered "Connected" when it receives the EAPoL Logoff packet from the server, this is not yet implemented.
* added a SidebySide Layout
* Reworked, so both screen have the same height and cleaned up screen translates.
* added the option in the UI, hope this is the right way to do it. formated framebuffer_layout.cpp
* delete the x64 files
* deleted ui_configure_graphics.h
* added Option for the Layout in the xml
* got rid of SIDE_BY_SIDE_ASPECT_RATIO because it was useless. pulled translate into variables
* changed shift variables to u32 and moved them in their respective branch. remove notr="true" for the Screen layout drop down
* reworked intends :). changed function description for SideFrameLayout
* some description reworking
Kernel/HLE: Use a mutex to synchronize access to the HLE kernel state between the cpu thread and any other possible threads that might touch the kernel (network thread, etc).
This mutex is acquired in SVC::CallSVC, ie, as soon as the guest application enters the HLE kernel, and should be acquired by the aforementioned threads before modifying kernel structures.
This is necessary for loading multiple processes at the same time.
The main thread will be automatically scheduled when necessary once the scheduler runs.
This function is called in clipping, before the pespective divide, and is not used in later rasterization. Thus it doesn't need perspective correction.
The geometry pipeline manages data transfer between VS, GS and primitive assembler. It has known four modes:
- no GS mode: sends VS output directly to the primitive assembler (what citra currently does)
- GS mode 0: sends VS output to GS input registers, and sends GS output to primitive assembler
- GS mode 1: sends VS output to GS uniform registers, and sends GS output to primitive assembler. It also takes an index from the index buffer at the beginning of each primitive for determine the primitive size.
- GS mode 2: similar to mode 1, but doesn't take the index and uses a fixed primitive size.
hwtest shows that immediate mode also supports GS (at least for mode 0), so the geometry pipeline gets refactored into its own class for supporting both drawing mode.
In the immediate mode, some games don't set the pipeline registers to a valid value until the first attribute input, so a geometry pipeline reset flag is set in `pipeline.vs_default_attributes_setup.index` trigger, and the actual pipeline reconfigure is triggered in the first attribute input.
In the normal drawing mode with index buffer, the vertex cache is a little bit modified to support the geometry pipeline. Instead of OutputVertex, it now holds AttributeBuffer, which is the input to the geometry pipeline. The AttributeBuffer->OutputVertex conversion is done inside the pipeline vertex handler. The actual hardware vertex cache is believed to be implemented in a similar way (because this is the only way that makes sense).
Both geometry pipeline and GS unit rely on states preservation across drawing call, so they are put into the global state. In the future, the other three vertex shader units should be also placed in the global state, and a scheduler should be implemented on top of the four units. Note that the current gs_unit already allows running VS on it in the future.
hwtest shows that, although GS always emit a group of three vertices as one primitive, it still respects to the topology type, as if the three vertices are input into the primitive assembler independently and sequentially. It is also shown that the winding flag in SETEMIT only takes effect for Shader topology type, which is believed to be the actual difference between List and Shader (hence removed the TODO). However, only Shader topology type is observed in official games when GS is in use, so the other mode seems to be just unintended usage.