Skip to content
Snippets Groups Projects
  1. Dec 28, 2018
  2. Dec 03, 2018
  3. Nov 22, 2018
    • Lioncash's avatar
      core: Relocate CPU core management to its own class · 232d95b5
      Lioncash authored
      Keeps the CPU-specific behavior from being spread throughout the main
      System class. This will also act as the home to contain member functions
      that perform operations on all cores. The reason for this being that the
      following pattern is sort of prevalent throughout sections of the
      codebase:
      
      If clearing the instruction cache for all 4 cores is necessary:
      
      Core::System::GetInstance().ArmInterface(0).ClearInstructionCache();
      Core::System::GetInstance().ArmInterface(1).ClearInstructionCache();
      Core::System::GetInstance().ArmInterface(2).ClearInstructionCache();
      Core::System::GetInstance().ArmInterface(3).ClearInstructionCache();
      
      This is kind of... well, silly to copy around whenever it's needed.
      especially when it can be reduced down to a single line.
      
      This change also puts the basics in place to begin "ungrafting" all of the
      forwarding member functions from the System class that are used to
      access CPU state or invoke CPU-specific behavior. As such, this change
      itself makes no changes to the direct external interface of System. This
      will be covered by another changeset.
      232d95b5
  4. Nov 18, 2018
  5. Oct 30, 2018
  6. Oct 28, 2018
  7. Oct 18, 2018
  8. Oct 15, 2018
  9. Oct 13, 2018
    • Lioncash's avatar
      filesystem: Make CreateFactories() and InstallInterface() take a VfsFilesystem... · 0149162d
      Lioncash authored
      filesystem: Make CreateFactories() and InstallInterface() take a VfsFilesystem instance by reference
      
      Neither of these functions alter the ownership of the provided pointer,
      so we can simply make the parameters a reference rather than a direct
      shared pointer alias. This way we also disallow passing incorrect memory values like
      nullptr.
      0149162d
  10. Oct 10, 2018
    • Lioncash's avatar
      kernel/thread: Use a regular pointer for the owner/current process · 5c040859
      Lioncash authored
      There's no real need to use a shared pointer in these cases, and only
      makes object management more fragile in terms of how easy it would be to
      introduce cycles. Instead, just do the simple thing of using a regular
      pointer. Much of this is just a hold-over from citra anyways.
      
      It also doesn't make sense from a behavioral point of view for a
      process' thread to prolong the lifetime of the process itself (the
      process is supposed to own the thread, not the other way around).
      5c040859
  11. Sep 29, 2018
  12. Sep 26, 2018
  13. Sep 15, 2018
  14. Sep 07, 2018
    • Lioncash's avatar
      core: Migrate current_process pointer to the kernel · 3f17fe71
      Lioncash authored
      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.
      3f17fe71
  15. Sep 06, 2018
    • Lioncash's avatar
      core/core: Remove unnecessary sm/controller include · 56ab6080
      Lioncash authored
      The only reason this include was necessary, was because the constructor
      wasn't defaulted in the cpp file and the compiler would inline it
      wherever it was used. However, given Controller is forward declared, all
      those inlined constructors would see an incomplete type, causing a
      compilation failure. So, we just place the constructor in the cpp file,
      where it can see the complete type definition, allowing us to remove
      this include.
      56ab6080
  16. Sep 04, 2018
  17. Sep 02, 2018
    • Lioncash's avatar
      vfs_real: Forward declare IOFile · a4053731
      Lioncash authored
      Eliminates the need to rebuild some source files if the file_util header
      ever changes. This also uncovered some indirect inclusions, which have
      also been fixed.
      a4053731
  18. Aug 31, 2018
    • Lioncash's avatar
      core/core: Replace includes with forward declarations where applicable · 4a587b81
      Lioncash authored
      The follow-up to e2457418, which
      replaces most of the includes in the core header with forward declarations.
      
      This makes it so that if any of the headers the core header was
      previously including change, then no one will need to rebuild the bulk
      of the core, due to core.h being quite a prevalent inclusion.
      
      This should make turnaround for changes much faster for developers.
      4a587b81
    • Lioncash's avatar
      core: Make the main System class use the PImpl idiom · e2457418
      Lioncash authored
      core.h is kind of a massive header in terms what it includes within
      itself. It includes VFS utilities, kernel headers, file_sys header,
      ARM-related headers, etc. This means that changing anything in the
      headers included by core.h essentially requires you to rebuild almost
      all of core.
      
      Instead, we can modify the System class to use the PImpl idiom, which
      allows us to move all of those headers to the cpp file and forward
      declare the bulk of the types that would otherwise be included, reducing
      compile times. This change specifically only performs the PImpl portion.
      e2457418
  19. Aug 29, 2018
    • Lioncash's avatar
      kernel: Eliminate kernel global state · 0cbcd6ec
      Lioncash authored
      As means to pave the way for getting rid of global state within core,
      This eliminates kernel global state by removing all globals. Instead
      this introduces a KernelCore class which acts as a kernel instance. This
      instance lives in the System class, which keeps its lifetime contained
      to the lifetime of the System class.
      
      This also forces the kernel types to actually interact with the main
      kernel instance itself instead of having transient kernel state placed
      all over several translation units, keeping everything together. It also
      has a nice consequence of making dependencies much more explicit.
      
      This also makes our initialization a tad bit more correct. Previously we
      were creating a kernel process before the actual kernel was initialized,
      which doesn't really make much sense.
      
      The KernelCore class itself follows the PImpl idiom, which allows
      keeping all the implementation details sealed away from everything else,
      which forces the use of the exposed API and allows us to avoid any
      unnecessary inclusions within the main kernel header.
      0cbcd6ec
  20. Aug 24, 2018
  21. Aug 12, 2018
  22. Aug 10, 2018
  23. Aug 09, 2018
  24. Aug 07, 2018
  25. Aug 04, 2018
    • Lioncash's avatar
      renderer_base: Make Rasterizer() return the rasterizer by reference · 2665457f
      Lioncash authored
      All calling code assumes that the rasterizer will be in a valid state,
      which is a totally fine assumption. The only way the rasterizer wouldn't
      be is if initialization is done incorrectly or fails, which is checked
      against in System::Init().
      2665457f
    • Lioncash's avatar
      video_core: Eliminate the g_renderer global variable · 6030c5ce
      Lioncash authored
      We move the initialization of the renderer to the core class, while
      keeping the creation of it and any other specifics in video_core. This
      way we can ensure that the renderer is initialized and doesn't give
      unfettered access to the renderer. This also makes dependencies on types
      more explicit.
      
      For example, the GPU class doesn't need to depend on the
      existence of a renderer, it only needs to care about whether or not it
      has a rasterizer, but since it was accessing the global variable, it was
      also making the renderer a part of its dependency chain. By adjusting
      the interface, we can get rid of this dependency.
      6030c5ce
  26. Aug 03, 2018
  27. Aug 02, 2018
    • Lioncash's avatar
      hw: Remove unused files · c6db1c39
      Lioncash authored
      None of these files are used in any meaningful way. They're just
      leftovers from citra. Also has the benefit of getting rid of an unused
      global variable.
      c6db1c39
    • Lioncash's avatar
      kernel: Move object class to its own source files · bf45092c
      Lioncash authored
      General moving to keep kernel object types separate from the direct
      kernel code. Also essentially a preliminary cleanup before eliminating
      global kernel state in the kernel code.
      bf45092c
    • Lioncash's avatar
      video_core: Make global EmuWindow instance part of the base renderer class · 0f2ac928
      Lioncash authored
      Makes the global a member of the RendererBase class. We also change this
      to be a reference. Passing any form of null pointer to these functions
      is incorrect entirely, especially given the code itself assumes that the
      pointer would always be in a valid state.
      
      This also makes it easier to follow the lifecycle of instances being
      used, as we explicitly interact the renderer with the rasterizer, rather
      than it just operating on a global pointer.
      0f2ac928
  28. Aug 01, 2018
  29. Jul 30, 2018
Loading