| Age | Commit message (Collapse) | Author |
|---|
|
It was reported that some games (Zelda Wind Waker and Zelda Twilight Princess but others may also exhibit the issue) have graphical issues with the max pixel samplers set to 16 on some Android devices (ex: Pixel6); since this was increased for a performance heavy feature (custom shaders) just disable it for now. In the future, this could be handled more elegantly
|
|
VideoBackends / VideoCommon: update max pixel shader samplers from 8 to 16
|
|
2D texture, a texture array, or a cube map; support 2D texture type across backends
Co-authored-by: TellowKrinkle <tellowkrinkle@gmail.com>
|
|
this allows us to support more samplers than the native Wii/GC
|
|
Crosses off a lingering TODO.
Also amends a few nearby cases where a u32 cast was being repromoted to
size_t.
|
|
|
|
Co-authored-by: TellowKrinkle <tellowkrinkle@gmail.com>
|
|
materials (slot 3, geometry shader buffer moves to slot 4 if available)
|
|
|
|
VideoBackends: support multiple compute images for some backends
|
|
|
|
Vulkan)
|
|
(and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
|
|
swapchain format)
|
|
Mirrors the C++23 <utility> function, std::to_underlying
|
|
... using libadrenotools
|
|
OpenGL: Check the list of supported AA modes instead of hardcoding
|
|
VideoBackends: add support to allow rendering to multiple output targets
|
|
|
|
|
|
|
|
Gets the interface out of the global namespace.
|
|
VideoBackends:Vulkan: Clean up submission thread using WorkQueueThread
|
|
It is used as workaround for the missing subgroupBroadcastDynamicId flag on SPIR-V < 1.5.
|
|
|
|
|
|
|
|
Android: Fix armeabi-v7a build
|
|
This very much isn't a build configuration that we're going to ship,
but I want to be able to tell people that they can build it on their
own if they really want to see how terribly it performs :)
Just like before, you'll need to edit two lines in app/build.gradle to
define ENABLE_GENERIC=ON and actually enable armeabi-v7a if you want an
armeabi-v7a build. This commit just fixes some compilations errors that
crop up if you do so.
|
|
|
|
VideoCommon: add constant value for maximum number of pixel samplers
|
|
VideoBackend/OGL: Prefer KHR_shader_subgroup over NV_shader_thread.
|
|
samplers
|
|
While the NV extension is totally fine, the KHR extension should be able to support more hardware.
For NVIDIA, the hardware either supports both or neither, it just needs a driver from the last two years.
For AMD, the drivers from late 2022-12 seems to bring support for the KHR extension.
For Intel, the KHR is also supported for some years.
|
|
the pipeline itself, so that it's easy to duplicate pipelines with slightly altered configuration
|
|
Kill Renderer (with phire)
|
|
Co-authored-by: Mai <mathew1800@gmail.com>
Co-authored-by: BhaaL <bhaalsen@gmail.com>
Co-authored-by: iwubcode <iwubcode@users.noreply.github.com>
|
|
|
|
|
|
And fix bug where opengl was getting the wrong coordinates
|
|
VideoBackends: add a way to load data into a specific level AND layer
|
|
|
|
|
|
Both DX12 and Vulkan already had one.
|
|
|
|
|
|
|
|
The whole ownership model was getting a bit of a mess, with a some
of special cases to deal with. And I'm planning to make it even more
complex in the future.
So here is some upfront work to convert it over to reference counted
pointers.
|
|
Ignore nullability-completeness warnings in VMA
|
|
These cause a lot of warnings when compiling with clang.
And the example VmaUsage.h appears to disable them
|
