Skip to content
Snippets Groups Projects
  1. Apr 12, 2019
    • Lioncash's avatar
      core/process: Remove unideal page table setting from LoadFromMetadata() · 32a6ceb4
      Lioncash authored
      Initially required due to the split codepath with how the initial main
      process instance was initialized. We used to initialize the process
      like:
      
      Init() {
          main_process = Process::Create(...);
          kernel.MakeCurrentProcess(main_process.get());
      }
      
      Load() {
          const auto load_result = loader.Load(*kernel.GetCurrentProcess());
          if (load_result != Loader::ResultStatus::Success) {
              // Handle error here.
          }
          ...
      }
      
      which presented a problem.
      
      Setting a created process as the main process would set the page table
      for that process as the main page table. This is fine... until we get to
      the part that the page table can have its size changed in the Load()
      function via NPDM metadata, which can dictate either a 32-bit, 36-bit,
      or 39-bit usable address space.
      
      Now that we have full control over the process' creation in load, we can
      simply set the initial process as the main process after all the loading
      is done, reflecting the potential page table changes without any
      special-casing behavior.
      
      We can also remove the cache flushing within LoadModule(), as execution
      wouldn't have even begun yet during all usages of this function, now
      that we have the initialization order cleaned up.
      32a6ceb4
    • Lioncash's avatar
      core/core: Move main process creation into Load() · a4b0a855
      Lioncash authored
      Now that we have dependencies on the initialization order, we can move
      the creation of the main process to a more sensible area: where we
      actually load in the executable data.
      
      This allows localizing the creation and loading of the process in one
      location, making the initialization of the process much nicer to trace.
      a4b0a855
    • Lioncash's avatar
      video_core/gpu: Create threads separately from initialization · 6d055119
      Lioncash authored
      Like with CPU emulation, we generally don't want to fire off the threads
      immediately after the relevant classes are initialized, we want to do
      this after all necessary data is done loading first.
      
      This splits the thread creation into its own interface member function
      to allow controlling when these threads in particular get created.
      6d055119
    • Lioncash's avatar
      core/cpu_core_manager: Create threads separately from initialization. · f2331a80
      Lioncash authored
      Our initialization process is a little wonky than one would expect when
      it comes to code flow. We initialize the CPU last, as opposed to
      hardware, where the CPU obviously needs to be first, otherwise nothing
      else would work, and we have code that adds checks to get around this.
      
      For example, in the page table setting code, we check to see if the
      system is turned on before we even notify the CPU instances of a page
      table switch. This results in dead code (at the moment), because the
      only time a page table switch will occur is when the system is *not*
      running, preventing the emulated CPU instances from being notified of a
      page table switch in a convenient manner (technically the code path
      could be taken, but we don't emulate the process creation svc handlers
      yet).
      
      This moves the threads creation into its own member function of the core
      manager and restores a little order (and predictability) to our
      initialization process.
      
      Previously, in the multi-threaded cases, we'd kick off several threads
      before even the main kernel process was created and ready to execute (gross!).
      Now the initialization process is like so:
      
      Initialization:
        1. Timers
      
        2. CPU
      
        3. Kernel
      
        4. Filesystem stuff (kind of gross, but can be amended trivially)
      
        5. Applet stuff (ditto in terms of being kind of gross)
      
        6. Main process (will be moved into the loading step in a following
                         change)
      
        7. Telemetry (this should be initialized last in the future).
      
        8. Services (4 and 5 should ideally be alongside this).
      
        9. GDB (gross. Uses namespace scope state. Needs to be refactored into a
                class or booted altogether).
      
        10. Renderer
      
        11. GPU (will also have its threads created in a separate step in a
                 following change).
      
      Which... isn't *ideal* per-se, however getting rid of the wonky
      intertwining of CPU state initialization out of this mix gets rid of
      most of the footguns when it comes to our initialization process.
      f2331a80
  2. Apr 11, 2019
  3. Apr 10, 2019
  4. Apr 09, 2019
    • Fernando Sahmkow's avatar
      Correct Fermi Copy on Linear Textures. · cd91e98d
      Fernando Sahmkow authored
      cd91e98d
    • Lioncash's avatar
      kernel/process: Set page table when page table resizes occur. · 2abf979c
      Lioncash authored
      We need to ensure dynarmic gets a valid pointer if the page table is
      resized (the relevant pointers would be invalidated in this scenario).
      
      In this scenario, the page table can be resized depending on what kind
      of address space is specified within the NPDM metadata (if it's
      present).
      2abf979c
    • Lioncash's avatar
      yuzu/loading_screen: Resolve runtime Qt string formatting warnings · b73e433d
      Lioncash authored
      In our error console, when loading a game, the strings:
      
      QString::arg: Argument missing: "Loading...", 0
      QString::arg: Argument missing: "Launching...", 0
      
      would occasionally pop up when the loading screen was running. This was
      due to the strings being assumed to have formatting indicators in them,
      however only two out of the four strings actually have them.
      
      This only applies the arguments to the strings that have formatting
      specifiers provided, which avoids these warnings from occurring.
      b73e433d
  5. Apr 08, 2019
  6. Apr 07, 2019
  7. Apr 06, 2019
Loading