1. 02 Sep, 2018 2 commits
  2. 01 Sep, 2018 2 commits
  3. 31 Aug, 2018 17 commits
  4. 30 Aug, 2018 4 commits
  5. 29 Aug, 2018 6 commits
    • tech4me's avatar
      Shaders: Implemented IADD3 · a6dd577d
      tech4me authored
      a6dd577d
    • fearlessTobi's avatar
      Show game compatibility within yuzu · 78653f73
      fearlessTobi authored
      78653f73
    • fearlessTobi's avatar
      Remove Citra specific variable · 02dfbf96
      fearlessTobi authored
      02dfbf96
    • liushuyu's avatar
      travis: share env variables with Docker · a2c97de9
      liushuyu authored
      a2c97de9
    • bunnei's avatar
    • 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
  6. 28 Aug, 2018 9 commits
    • bunnei's avatar
      Merge pull request #1193 from lioncash/priv · 4d7e1662
      bunnei authored
      gpu: Make memory_manager private
      4d7e1662
    • bunnei's avatar
      Merge pull request #1192 from lioncash/unused · eb4f2d55
      bunnei authored
      gl_rasterizer: Remove unused variables
      eb4f2d55
    • bunnei's avatar
      Merge pull request #1191 from lioncash/noexcept · d8ba2020
      bunnei authored
      hle/result: Make ResultVal's move constructor as noexcept
      d8ba2020
    • bunnei's avatar
      Merge pull request #1194 from lioncash/alloc · 72e4499a
      bunnei authored
      gl_shader_cache: Remove unused program_code vector in GetShaderAddress()
      72e4499a
    • Lioncash's avatar
      gl_shader_cache: Remove unused program_code vector in GetShaderAddress() · 2e7dc4ca
      Lioncash authored
      Given std::vector is a type with a non-trivial destructor, this
      variable cannot be optimized away by the compiler, even if unused.
      Because of that, something that was intended to be fairly lightweight,
      was actually allocating 32KB and deallocating it at the end of the
      function.
      2e7dc4ca
    • Lioncash's avatar
      gpu: Make memory_manager private · 45fb74d2
      Lioncash authored
      Makes the class interface consistent and provides accessors for
      obtaining a reference to the memory manager instance.
      
      Given we also return references, this makes our more flimsy uses of
      const apparent, given const doesn't propagate through pointers in the
      way one would typically expect. This makes our mutable state more
      apparent in some places.
      45fb74d2
    • Lioncash's avatar
      gl_rasterizer: Remove unused variables · 6771a18c
      Lioncash authored
      6771a18c
    • bunnei's avatar
      Merge pull request #1190 from FearlessTobi/im-so-retarded · 0d243534
      bunnei authored
      yuzu: Fix two stupid errors made in #1141
      0d243534
    • Lioncash's avatar
      hle/result: Make ResultVal's move constructor as noexcept · f1bc62bb
      Lioncash authored
      Many containers within the standard library provide different behaviors
      based on whether or not a move constructor/assignment operator can be
      guaranteed not to throw or not.
      
      Notably, implementations will generally use std::move_if_noexcept (or an
      internal implementation of it) to provide strong exception guarantees.
      If a move constructor potentially throws (in other words, is not
      noexcept), then certain behaviors will create copies, rather than moving
      the values.
      
      For example, consider std::vector. When a std::vector calls resize(),
      there are two ways the elements can be relocated to the new block of
      memory (if a reallocation happens), by copy, or by moving the existing
      elements into the new block of memory. If a type does not have a
      guarantee that it will not throw in the move constructor, a copy will
      happen. However, if it can be guaranteed that the move constructor won't
      throw, then the elements will be moved.
      
      This just allows ResultVal to be moved instead of copied all the time if
      ever used in conjunction with containers for whatever reason.
      f1bc62bb