Largely similar to D3D12 implementation but more simple buffer
management and no mips scaling. Includes both FBO and FSI
rendering paths.
Tested on Linux with 2x2 and 3x3 running smoothly.
- Simplified handling of notifications to faster version with ranges
- Removed usage of STB sprintf on checked due to ASAN violation
- Draw ImGui windows only when they're not in close_pending state
- Disabled unnecessary hotkeys thread when it is not used
- Removed problematic xam_exports static initialization
- Moved xam_dialogs_shown_ and xam_nui_dialogs_shown_ to XamState
Rather than manually release the lock inside the loop, which breaks RAII
and introduces undefined behavior, we separate the controller state gathering
operation from the rumble hotkey processing loop. The lock lifecycle
is now automatically managed by scope.
On a side note, with multiple controllers connected this would probably
have become clear that it's broken sooner but I guess that's not a very
common use case.
Enable portability subset physical device enumeration.
Don't use Vulkan 1.1+ logical devices on Vulkan 1.0 instances due to the
VkApplicationInfo::apiVersion specification.
Make sure all extension dependencies are enabled when creating a device.
Prefer exposing feature support over extension support via the device
interface to avoid causing confusion with regard to promoted extensions
(especially those that required some features as extensions, but had those
features made optional when they were promoted).
Allow creating presentation-only devices, not demanding any optional
features beyond the basic Vulkan 1.0, for use cases such as internal tools
or CPU rendering.
Require the independentBlend feature for GPU emulation as working around is
complicated, while support is almost ubiquitous.
Move the graphics system initialization fatal error message to xenia_main
after attempting to initialize all implementations, for automatic fallback
to other implementations in the future.
Log Vulkan driver info.
Improve Vulkan debug message logging, enabled by default.
Refactor code, with simplified logic for enabling extensions and layers.
VS/PS_NUM_REG is 6-bit on Adreno 200, and games aren't seen using the
bit 7 to indicate that no GPRs are used. It's not clear why Freedreno
configures it this way.
Some texture fetch fields were deprecated or moved during the development
of the Xenos, reflect that in the comments.
Add definitions of the registers configuring the conversion of vertex
positions to fixed-point. Although there isn't much that can be done with
it when emulating using PC GPU APIs, there are some places in Xenia that
wrongly (though sometimes deliberately, for results closer to the behavior
of the host GPU) assume that the conversion works like in Direct3D 10+,
however the Xenos supports only up to 4 subpixel bits rather than 8. The
effects of this difference are largely negligible, though.
Also add more detailed info about register references and differences from
other ATI/AMD GPUs for potential future contributors.
