aboutsummaryrefslogtreecommitdiff
path: root/src/video_core/vulkan_common
Commit message (Collapse)AuthorAgeFilesLines
* video_core: accept an empty Streamline device-extension listDuck9127 hours1-5/+4
| | | | | | | | | | | Streamline may report that DLSS needs no extra device extensions. The check required a non-empty list, so that result counted as "extensions unavailable": Streamline was stopped and FSR 3.1 used. Only require that every listed extension is supported. Found by CodeRabbit review. Assisted-by: Claude Opus 5.5 (implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
* video_core, yuzu: write NVIDIA DLSS file paths to logs as UTF-8Duck9128 hours1-7/+10
| | | | | | | | | | | | | | | The Streamline start-up and DLSS download code formatted paths with std::filesystem::path::string(), which on MSVC converts to the active code page and throws when a character has no mapping there, for example a user name in another script under %APPDATA%. The start-up log runs inside the renderer's constructor, which only catches vk::Exception, so such a user would crash at game start with the setting on. Use Common::FS::PathToUTF8String for every path in these logs and messages. Found by CodeRabbit review. Assisted-by: Claude Opus 5.5 (implementation) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
* video_core: NVIDIA DLSS through NVIDIA Streamline in place of a game's DLSSDuck9128 hours6-0/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds a Graphics setting, "Use NVIDIA DLSS in place of a game's DLSS" (nvidia_dlss, off by default). When it is on, in Windows builds configured with EGLANTINE_STREAMLINE_SDK, the evaluation Eglantine already replaces with FSR 3.1 goes to NVIDIA DLSS on GeForce RTX cards, with the same inputs (colour, depth, motion vectors, jitter). When DLSS can't run, FSR 3.1 runs as before. Only Streamline's MIT-licensed headers are compiled in; nothing of NVIDIA's is linked or shipped. At run time Eglantine looks for sl.interposer.dll in the user folder's "streamline" folder (or EDEN_STREAMLINE_DIR, or "streamline" next to the executable), checks its Streamline signature and starts Streamline with manual hooking. Streamline's plugins come from that folder or the NVIDIA app's downloads. DLSS itself is nvngx_dlss.dll in the same folder, else the newest DLSS 310 or later that the NVIDIA app has downloaded, checked for NVIDIA's Authenticode signature and copied as streamline/nvidia-app/nvngx_dlss.dll. Like other tools that call DLSS outside a game, it uses its own fixed project id with the custom engine type. - Preset K for all modes (EDEN_NX2_DLSS_PRESET overrides it): the default Performance model (M) and L draw thin dark horizontal lines in some frames at 2x resolution scale; K doesn't. - HDR input with auto exposure; the mode follows the render/output ratio. - Buffer device address stays enabled when DLSS needs it, for DLSS only. - The upscaler waits for the device instead of submitting when it is destroyed: by then the game's channels are released, and a submit read the state tracker's stale flags (a crash when stopping a game). With the setting off, or in builds without the SDK path (the setting is hidden there), nothing changes. Testing: Windows 11, RTX 5080, Fire Emblem: Fortune's Weave docked at 1x (720p -> 1440p) and 2x (1440p -> 2880p), CLI runs and GUI play, stopping and restarting games with DLSS on. Not tested on other GPUs or games. Assisted-by: Claude Opus 5.5 (implementation, debugging) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
* Merge remote-tracking branch 'origin/nx2' into fe-fsr31Duck91226 hours1-0/+6
|\ | | | | | | | | | | # Conflicts: # src/video_core/renderer_vulkan/blit_image.cpp # src/video_core/renderer_vulkan/blit_image.h
| * vulkan: repack 69-byte vertices without dynamic vertex input on MoltenVKSssnowyyy30 hours1-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | e38b738b84 repacks the 69-byte vertex stride to 72 only with dynamic vertex input, unless EGLANTINE_EXPERIMENTAL_STATIC_VERTEX_REPACK=1. MoltenVK has no VK_EXT_vertex_input_dynamic_state and Metal needs strides that are a multiple of 4, so the stride was never fixed on Macs. Enable the static path automatically when the device's minimum vertex binding stride alignment does not divide 69. The device reports 4 for MoltenVK, matching its portability subset limit. The environment variable still overrides it: 1 forces the repack on, 0 forces it off. Assisted-by: Claude Sonnet 5.5 (implementation and commit message)
* | video_core: replace Fortune's Weave's DLSS with AMD FSR 3.1Duck91228 hours1-0/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fire Emblem: Fortune's Weave's DLSS network can't run here, and the temporal stand-in is only an approximation of it. FSR 3.1 takes the same inputs DLSS does: the jittered colour, motion vectors, the jitter and the depth, which the game's first DLSS pass reads through cbuf0+0x298 (Z32, reversed, the colour's size). Kepler compute keeps it next to the motion vectors. Fsr3Upscaler ports the host side of the SDK's ffx_fsr3upscaler.cpp: the eight passes (prepare inputs, luma and shading-change pyramids, shading change, reactivity, luma instability, accumulate, RCAS), the internal images and the constants, recorded through the scheduler with the shaders from externals/FidelityFX-SDK. It takes HDR colour, render-size motion vectors and reversed depth, computes its own exposure, and uses the no-wave SPD variants on devices without compute quad operations. The SDK's GLSL uses separate textures and samplers, so DescriptorBankInfo gains sampled image and sampler counts (default 0). FSR's RCAS follows the RCAS Sharpness slider. The result goes to FSR's own RGBA16F image and is drawn into the game's output, which keeps its format. TextureCacheRuntime::TemporalUpscale runs FSR 3.1 first. Without the depth, at mismatched scales, on a device lacking FSR's formats or features, or if its pipelines fail to build, the stand-in runs instead, and the bilinear blit stays last. EDEN_NX2_DLSS_REPLACEMENT=standin forces the stand-in. A gap of more than 250 ms between evaluations restarts the history. The BlitColor overload that takes a raw image view transitions its source to SHADER_READ_ONLY_OPTIMAL but described it as GENERAL in the descriptor (a validation error); it now describes the layout it uses. Assisted-by: Claude Opus 5.5 (debugging, implementation and drafting) Signed-off-by: Duck912 <350528965+Duck912@users.noreply.github.com>
* texture_cache: keep the allocator's block slack out of the usable VRAMkraibse2 days2-1/+17
| | | | | | | | | | | | | | The collector's usage leaves out the unused part of VMA's blocks, but the driver counts it and a heap at its budget cannot give it to a new image. On an RX 7800 XT that slack was 1.06 GiB, the whole 1 GiB margin: the heap sat at its budget for a minute while the collector saw room, then images stopped fitting and the process died. Reserve the slack (capped at 1.5 GiB) on top of the margin: at once when it grows, slowly when it shrinks, so eviction leaving partly used blocks doesn't chase the threshold down. Assisted-by: Claude Sonnet 5.5 (diagnosis and code) (cherry picked from commit 73fd5a489ea28226fa16a55f5008e622d631b54c)
* vulkan: don't make small images unbacked when device memory runs outkraibse2 days2-0/+29
| | | | | | | | | | When VRAM ran out, any image that failed to allocate became a sparse image with nothing bound, which AMD's drivers don't survive being sampled (an RX 6600 died mid-flood, an RX 7800 XT made 211 of them, 8x8 ones included). Try host memory first, and count the images that didn't fit: the texture cache then keeps more room under the budget (512 MiB a step, up to 3 GiB, decaying) so its collector runs earlier. The sparse fallback stays for images too large to back.
* texture_cache: collect images in the emptiest device memory blocks firstTakoroka2 days2-0/+22
| | | | | | | | | | | | Deleting by age alone left every block partly used: the collector deletes thousands of images a minute and new ones land in the holes, so blocks seldom empty (title 1: ~0.8 GB of holes in ~190 32 MiB blocks after ten minutes, counted by the driver as used). Among the oldest candidates, 8 per image a pass may delete, those in the emptiest blocks go first, so blocks drain and VMA returns them; placement already prefers the fullest blocks. (cherry picked from commit 2f8f0716fafd874cfbb3cc9086141aea61aff2df)
* Merge remote-tracking branch 'origin/fix/vk-memory-blocks' into ↵Takoroka2 days4-5/+120
|\ | | | | | | test/linux-all-prs
| * vulkan: 16 MiB memory blocksTakoroka2 days2-5/+6
| | | | | | | | | | | | | | | | With 32 MiB blocks title 1 still had ~0.5 GB of holes between images: a block drains only once all of its images are gone, and fewer per block drain sooner. Allocations over 8 MiB get memory of their own. (cherry picked from commit d3a4db818512221e6b0555e886e192c346c16ae7)
| * vulkan: keep sparse pages and device-local buffers out of the image blocksTakoroka2 days4-1/+109
| | | | | | | | | | | | | | | | | | | | About half of the holes in the default blocks sat next to buffers (~1,100, churned by the buffer cache's collector) or sparse pages (~2,400 64 KiB-4 MiB allocations), which the texture cache's collector can't move. Each gets a VMA pool of its own per memory type (32 MiB blocks); allocations over half a block, or ones the pool fails, take the default blocks. (cherry picked from commit 6c5ad324bd79ec50601ae14a63ca745da612f61f)
| * vulkan: 32 MiB memory blocks and best-fit placement for imagesTakoroka2 days2-4/+10
| | | | | | | | | | | | | | | | | | Textures created and deleted by the thousand still left about 1.7 GB of the 64 MiB blocks empty after ten minutes of title 1. Smaller blocks go back to the driver sooner, VMA gives allocations over 16 MiB their own memory, and the min-memory strategy fills holes before taking a block. (cherry picked from commit 6235081422f2bd2d726ccb45354c46d7c3ed2a0e)
* | Merge remote-tracking branch 'origin/fix/nx2-igpu-stream-buffer' into ↵Takoroka2 days1-0/+5
|\ \ | | | | | | | | | test/linux-all-prs
| * | vulkan: keep the stream buffer within a small iGPU heapTakoroka3 days1-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The stream buffer prefers device-local host-visible memory. On a Radeon 780M that is a 256 MiB heap with a 243 MiB budget, and the 256 MiB buffer alone kept it over budget for the whole session ("VMA heap 2: usage 256 MiB of budget 243 MiB"). On integrated GPUs whose device-local host-visible heap is no bigger than the stream buffer, use three quarters of the heap instead (192 MiB there). Radeon 780M, Mario Kart World title screen: heap 2 at 192 of 243 MiB, picture and frame rate unchanged.
* | | Merge remote-tracking branch 'origin/feat/nx2-mesh-shaders' into ↵Takoroka2 days4-0/+22
|\ \ \ | |_|/ |/| | | | | test/linux-all-prs
| * | video_core: draw Switch 2 task/mesh pipelines with VK_EXT_mesh_shaderTakoroka2 days4-0/+22
| |/ | | | | | | | | | | | | | | | | | | | | | | | | While SET_MESH_CONTROL is on, a native draw binds a task program in the vertex slot, its mesh program in the tessellation slot and a header-only pass-through geometry program naming the per-primitive outputs. Translate the first two as task and mesh programs with the mesh registers (SET_MESH_SHADER_A/B, SET_MESH_INIT_SHADER) and that header, key their pipelines by them, and build pipelines with task/mesh stages and no vertex input, input assembly or tessellation state. The draw's vertex count is the number of task workgroups: record vkCmdDrawMeshTasksEXT. Enable VK_EXT_mesh_shader (task and mesh only) when the host has it; draws are skipped without it, as they were before.
* | vulkan: treat RADV like the other AMD drivers for unbound sparse imageskraibse2 days1-2/+12
| | | | | | | | | | Add EDEN_NX2_SPARSE_UNBACKED=0/1 to force unbound sparse images off or on on any driver, so Linux AMD testers can check whether RADV needs this.
* | vulkan: share one zeroed block between empty sparse blocks on AMDTakoroka2 days3-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AMD's drivers can't sample images with unbound memory, so large sparse images are backed whole there, Mario Kart World's nine sparse masks included (about 2.9 GB, re-uploaded whole for every tile the game maps). Where the driver supports sparseResidencyAliased, SparseTiles images are now created with VK_IMAGE_CREATE_SPARSE_ALIASED_BIT and every block is bound to one zeroed 64 KiB block when the image is created (the image is cleared once); a block gets memory of its own when data arrives, as on other drivers. Nothing is ever left unbound. If the GPU renders into such an image, every block gets memory of its own first, cleared, and the data is loaded again, so the shared block stays zero. EDEN_NX2_SPARSE_ALIASED=1 uses the shared block wherever it is supported, =0 never. Radeon 780M (proprietary driver 32.0.31041), Mario Kart World title screen, 200 s: no hang or device loss, world lit, shared memory 12.7 GB at the end growing 1.8 GB/min, against 18.7 GB and 5.1 GB/min with the masks backed whole. With every sparse image unbound instead (no AMD fallback at all) the static world renders dark there, so the other large sparse images stay backed whole on AMD.
* | vulkan: back large sparse images normally on AMDkraibse2 days1-0/+8
| | | | | | | | | | | | | | Lazy Switch 2 sparse regions made the texture cache create large images with no memory bound and sample them. AMD's drivers crash shortly after the first such draw (builds 49+). Skip the unbacked-image paths on AMD drivers; images get regular backing as in build 47.
* | vulkan_device: tell AMD GCN4 apart before float16 is turned offTakoroka2 days1-2/+6
| | | | | | | | | | | | | | | | | | | | AMD GCN4 and older are recognised by their lack of float16. Since float16 is turned off for every non-Mesa AMD driver (2026+ versions break it), the sampler min/max check that runs after that saw every AMD GPU as GCN4 and removed VK_EXT_sampler_filter_minmax: a Radeon 780M (RDNA3) logged "AMD GCN4 and earlier have broken VK_EXT_sampler_filter_minmax", and samplers with a min/max reduction fell back to plain filtering there. Read it once, before float16 is turned off.
* | vulkan_device: keep an integrated GPU's budget within its memory shareTakoroka2 days1-0/+7
|/ | | | | | | | | | | | | | | CollectPhysicalMemoryInfo gives an integrated GPU 4 GiB of device memory (6 GiB with aggressive VRAM use), since its device-local heap is system memory. GetDeviceMemoryBudget returned the heap's driver budget instead (21178 MiB on a Radeon 780M), and the texture cache follows that budget for Switch 2 titles: it collected only past 20.6 GB, filling system RAM, and kept ASTC uncompressed (the BC3 switch looks at the budget too). Cap it at that share. Radeon 780M, Mario Kart World title screen, 200 s: shared GPU memory 2.7 -> 3.6 GB instead of 7.6 -> 12.7 GB (0.25 instead of 1.8 GB/min), private bytes 12.9 instead of 22.4 GB at the end, ASTC re-compressed to BC3, same frame rate.
* 1st pass of review: code cleanup & windows testnéo Luigi3 days1-22/+26
| | | | Assisted-by: Claude Opus 5.5 (review, cleanup and log analysis)
* texture_cache: keep Switch 2 VRAM use under the driver's budgetWael3rd3 days2-7/+53
| | | | | | | | | | | | | | | | | | Mario Kart World filled the GPU after a few minutes on 8 GB cards, and on 16 GB cards with uncompressed ASTC: textures were created without memory (garbage), then the emulator crashed. The Switch 2 collector thresholds came from the sum of all heap budgets, but on AMD the host-visible device-local heap is the same VRAM, so the critical threshold ended above the real budget and the collector never kicked in. Unbacked images were also counted at their full size. Thresholds now follow the main device-local heap's budget, re-read every 30 frames, and images count the memory they really have. Switch 2 titles on GPUs under 12 GiB re-compress ASTC to BC3 for the session when it is set to Uncompressed (EDEN_NX2_KEEP_ASTC=1 opts out), and EDEN_NX2_VRAM_LIMIT_MIB simulates a smaller GPU for testing. Assisted-by: Claude Opus 5.5 (diagnosis and code)
* vulkan: bind memory to sparse terrain arrays layer by layerTakoroka4 days5-0/+55
| | | | | | | | | | | | | | | | | | | | | | | The written part of Mario Kart World's sparse terrain arrays is small: 13-26% of their blocks. The two 1.45 GB ASTC arrays were backed in full on the host, and the two 5.8 GB BC6H arrays, too large to back, stayed unbacked, so what the game streamed into them never showed. A color array of 32 MiB or more lying in one sparse region, in a format uploaded layer by layer (huge ASTC arrays decoded on the GPU, or formats sampled as they are), is now a sparse resident image (SparseLayers). When it is refreshed, the layers written since (or, for a new image, the layers any of whose blocks was written) get device memory bound with vkQueueBindSparse (under the submit lock, waited on, as the multi-range buffer cache does) and only those layers are uploaded. Unwritten layers read zero. One image binds at most 768 MiB (384 MiB on GPUs with less than 7 GiB); rendering into one binds all its layers. Mario Kart World, 180 s: the ASTC arrays hold 1.4 MiB per written layer, four BC6H layers (341 MiB) now have their data, device memory in use 4.8-5.0 GB instead of 6.0-7.1 GB with the texture cache below its collection threshold, 16.8-17.2 ms average frames, peak working set 13.4 GB.
* texture_cache: give images over unwritten sparse blocks no device memoryTakoroka4 days2-10/+23
| | | | | | | | | | | | | | | | | | | | | Mario Kart World creates nine terrain layer pools in sparse regions (four R8 16384x16384, four RG16 8192x8192, one R16 8192x8192: 2.9 GB of device memory). In 180 s of title and attract demo not one of their blocks is written and nothing renders into them, so they hold zeros; on the console only the few tiles the game maps have memory. nx2:gpu now publishes which 4 MiB blocks of each sparse region have been written (nx2.h, a leaf lock the texture cache may take). An image of 32 MiB or more lying in one sparse region with no written block is created as a sparse resident image with nothing bound: reads return zero, as an unmapped tile does. The first write into its range, or the first time the GPU renders into it (that range then counts as written), marks it remapped, so a backed image replaces it at its next use. Mario Kart World, 180 s: the collector deletes 0-80 images per 600 frames instead of thousands, frames over 100 ms per 600 presents drop from 1-9 to 0-1, peak working set 14.7 GB. One render target in a small sparse region gets replaced once (logged).
* nx2: log per-call and periodic diagnostic lines at debug levelTakoroka5 days1-1/+1
| | | | | | | | | | | A 9-minute Mario Kart World session wrote 36k log lines at the default level, most of them one per GPU call: nx2:syncpt 201/202 (12k), gpu submit jobs (7k), memory registrations (7k), "Lowered native shader" (1.6k), and 4.7k "Storage buffer tracked without bias" warnings, which every Switch 2 shader hits. These, the texture cache's per-image and per-format detail lines, the 3D image shapes and the per-type VMA lines are now debug level. The once-a-report summary lines (texture cache memory, images created/deleted, VMA heap budget) stay at info.
* vulkan: 64 MiB VMA blocks; device memory usage without VMA block slackTakoroka6 days2-4/+19
| | | | | | | | | | | | | | | | Title 1's texture cache deleted 1,400-2,600 textures per 600 frames and created them again: device memory sat at the collector's critical line, but ~38% of it was empty space in 256 MiB VMA blocks. Freeing an image returns that space only once its whole block is empty, so the caches kept collecting without the usage dropping (one mass purge deleted 4,300 textures). - 64 MiB blocks on discrete GPUs too (as on integrated ones). - GetDeviceMemoryUsage subtracts the unused bytes in VMA blocks, so each eviction counts at once. Now 0-224 deletions per 600 frames, ~4,400 textures resident, and driver usage 6.24 GB of a 6.97 GB budget.
* ASTC: decode and re-compress to BC1/BC3 on the GPU; texture cache budgetTakoroka6 days4-3/+24
| | | | | | | | | | | | | | | | | | | - accelerate_astc=Gpu with astc_recompression=Bc1/Bc3 now decodes ASTC with the GPU decoder into a temporary RGBA8 image (dedicated memory, freed once the GPU is past it) and compresses it with a new compute shader (bc_encoder.comp: bounding-box endpoints along the colours' covariance, inset 1/16, nearest palette entry; BC3 alpha ramp; BC1 punch-through), then copies the blocks into the image. No CPU decode, so streamed textures are ready the frame they are first used instead of showing placeholders for seconds; the decode pass no longer waits for the GPU on this path. - The CPU path (CpuAsynchronous) fills a new image with zero blocks before its first decode instead of showing stale VRAM, and the transcode pool is a quarter of the hardware threads. - Switch 2 titles: collector thresholds near the device budget, re-read every 60 frames from VK_EXT_memory_budget (another game shrank it from 7.0 to 5.4 GB). - EDEN_NX2_HIDE_WINDOW=0 now leaves the window visible.
* Texture cache: log VMA blocks per memory type with the periodic memory logTakoroka6 days2-0/+29
| | | | | Device memory use is ~3 GB above what the images account for; this shows where. The per-decode log drops to debug level.
* Vulkan: unbacked sparse images for textures too large to backTakoroka6 days2-1/+52
| | | | | | | | | Title 1 samples an 8192x8192, 12-level, 68-layer array (a sparse virtual texture, ~23 GB): vkCreateImage failed and Eden aborted, or VMA put it in system memory and staged a full upload (34 GB private). Images over 2^28 texels are now created sparse-resident with no memory bound; the texture cache neither uploads nor downloads them. Images merely over the VRAM budget are allocated without the budget limit instead of failing.
* [shader_recompiler, vulkan, qcom, tu] Provide handling to missing shader ↵CamilleLaVey2026-10-141-0/+5
| | | | | | | | | | | | | | | | subgroups on QCOM (#4508) This works provides better emulation on certain GS missing for shader invocation data + geometry pass fallback in qcom/turnip drivers, some of those were provided as community patch by @a.kamaltdinov; which was refined to address the requirements on forced gpu reads; which used to kill some performance on low end devices; now, the stability with some of the graphical problems have been addressed and balanced. Shuffle shaders (SHFFL) are not actually provided on QCOM and turnip drivers, so any game that previously required this stage draw, will now avoid being ignored and tax some performance based on the complexity of the stage draw from now on. This will also address partially some tessellation problems as well. _Special Thanks:_ 1.- @a.kamaltdinov (for the initial patch "early fix for nier" provided for #4325) 2.- @PavelBARABANOV (because the making the cherry-pick easier for a new PR) Co-authored-by: PavelBARABANOV <pavelbarabanov94@gmail.com> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4508 Reviewed-by: lizzie <lizzie@eden-emu.dev> Reviewed-by: crueter <crueter@eden-emu.dev>
* revert [vulkan] Masquerade VkInfo as PUBGMobile + UE #4320 (#4520)PavelBARABANOV2026-10-111-15/+2
| | | | | | | | | | | | | - [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- https://github.com/Balemuni/Balemunis-Aurora stopped fixing the black squares in TotK. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4520 Reviewed-by: lizzie <lizzie@eden-emu.dev> Reviewed-by: Maufeat <sahyno1996@gmail.com>
* [vulkan] Masquerade VkInfo as PUBGMobile + UE (#4320)lizzie2026-09-081-2/+15
| | | | | | | | | | | | | | | | | | Signed-off-by: lizzie <lizzie@eden-emu.dev> - [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- PR I was talking about with @CamilleLaVey , please tell me if this is a stupid idea OR has a chance to work applicationname is a wild guess Co-authored-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4320 Reviewed-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-by: Maufeat <sahyno1996@gmail.com>
* [shader_recompiler, vulkan] Virtual buffer pages with multi-range + sparse ↵CamilleLaVey2026-09-086-7/+91
| | | | | | | | | | | | buffers binding (#4362) Storage buffers can span GPU pages that aren't contiguous in host memory, but the buffer cache assumed one contiguous buffer per binding, so anything crossing a mapping boundary read the wrong bytes. Multi-range binding resolves the real segments and presents them to the shader as one buffer, aliasing their memory into a sparse VkBuffer or gathering them into a copy, all of this was mostly fixed by making a path to use sparse on buffers (the same way as texture cache has it) and retrieve properly the mapping ranges to the virtual pages, including the actual structure on the use of binding sparse. Meanwhile this fixes Monster Hunter Sunbreak z-fighting, bad performance and mostly vertex explosions (coming from the contiguous buffer read from the shader's game) it's only the basis for a further investigation towards how are we gonna treat phi calculations, optimized them and mostly eradicate the currently excess of exposure on the textures where the lightning trace should not being reflected. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4362 Reviewed-by: lizzie <lizzie@eden-emu.dev> Reviewed-by: Maufeat <sahyno1996@gmail.com>
* [cmake] Fix some macOS compilation errors (#4350)lizzie2026-09-051-299/+278
| | | | | | | | | | | | | | | | | | | | Don't compile GLSL/GLASM backends without OpenGL enabled. These codepaths are unused on non-OpenGL platforms. Fixes other miscellaneous errors that pop up on Clang 23 as well. Signed-off-by: Lizzie lizzie@eden-emu.dev Signed-off-by: crueter crueter@eden-emu.dev - [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- Co-authored-by: crueter <crueter@eden-emu.dev> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4350 Reviewed-by: crueter <crueter@eden-emu.dev> Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
* [common] Switch to boost::unordered_flat containers (#4326)crueter2026-08-312-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Replaces all instances of ankerl's unordered map/set with boost's `unordered_flat_*` classes. This uses std::hash since boost::hash is actually a lot slower. Also adds an abstraction layer in `Common` so future changes are quicker and easier. Other implementation details: - ankerl provided hash specializations for tuple and pair, so those were ported here - std::erase_if doesn't work on boost, so just used the ADL'd erase_if This should be about equal or superior performance as unordered_dense for everything except iteration. Signed-off-by: crueter <crueter@eden-emu.dev> - [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4326 Reviewed-by: Lizzie and Samuel <lizzie@eden-emu.dev> Reviewed-by: MaranBr <maranbr@eden-emu.dev>
* [vulkan, vk_pipeline_cache] PSO Optimizations (#4294)Lizzie and Samuel2026-08-302-0/+109
| | | | | | | | | | | PR/Commit Owner: CamilleLaVey This PR prevents the recompilation of shaders when a new session has been started, based on data found on the recompiler, each new session does still recompile already cached shader cache, reducing the reaction and speed of games by at certain level, this prevent the warm-up with post sessions, only needed the initial warm-up and works globally for all games. Co-authored-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4294 Reviewed-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-by: Maufeat <sahyno1996@gmail.com>
* [vulkan] Implementation for VK_EXT_shader_quad_control (#4168)CamilleLaVey2026-08-282-0/+11
| | | | | | | | An experimental approach to introduce an smarter way to use and access QUAD's capabilities on shaders, suggested by @gidoly some months ago, finally came into something usable; current implementation checks GLASM, GLSL and Vulkan on their own way, stablishes proper emitters and receivers for Quads inside our recompiler, which are the introductions for future changes; checks for support and actual feature bit, OpCodes and mask were added within this PR. Meanwhile the expected behavior was to reduce graphical issues (on games with Quad shaders reliant), we encountered a very slight performance increase depending on what game and shader are actually compiled. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4168 Reviewed-by: MaranBr <maranbr@eden-emu.dev> Reviewed-by: Samuel <lizzie@eden-emu.dev>
* [vulkan] Removal of QCOM sampler limiters + CustomBorderColor and ↵CamilleLaVey2026-08-252-42/+43
| | | | | | | | | | ColorBorderSwizzle adjustments (#4301) This PR removes the artificial limit added for QCOM drivers based on a sampler budget limit (based on #3280 work), removes the ban on CustomBorderColor/BorderColorSwizzle for also QCOM driver, reduce the amount of combination required to created a sampler with custom border color/ color border swizzle; adds cases on R16 formats not able to swizzle on BGR565 formats; degrades samplers and color combinations when there's no color border swizzle available; fixes the srgb (LUT) values from legacy and now all the color variations are cached in the same key, instead of having 7 different handlers for them. In resume, rather than performance (due to the reduced amount of process on duplicated/ synced code on pipeline/texture cache), it's a graphica accuracy work that will improve image quality at the cost of almost 0 performance hit, rather than certain hitch if the color combination wasn't cached before. This applies to all platform. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4301 Reviewed-by: Samuel <lizzie@eden-emu.dev> Reviewed-by: MaranBr <maranbr@eden-emu.dev>
* [vulkan, qcom] Fix shader float controls on QCOM driver (#4297)CamilleLaVey2026-08-241-2/+0
| | | | | | | | | | | | Finishes my torture to find the culprit behind the broken behavior with float controls, even if device does support flush denorm on fp32 it doesn't really support it and provokes bad rounding modes by not flushing correctly denorms; this also returns the other working rounding modes on QCOM drivers. _Special Thanks_ 1.- Smoly The Big (@Gidoly) Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4297 Reviewed-by: Samuel <lizzie@eden-emu.dev> Reviewed-by: MaranBr <maranbr@eden-emu.dev>
* [vulkan] Adjustments on MSAA and BlitHelpers (#4287)crueter2026-08-234-12/+54
| | | | | | | | | | | | | | | PR/Commit Owner: CamilleLaVey This PR contains changes complementary to the MSAA refactor from some weeks ago, adds proper shader convert to depth, stencil for msaa and non msaa convertions; removes redundant helpers and unify paths on the resolve functions, just to make the readability and maintainability better; includes fixes for the blit operations on Nvidia, Intel/Windows (previously banned) and ensures Linux retain the fix without extra burden; fixes the QCOM driver bug on resolution upscaling on any games above x1 (includes turnip on A8xx series) and fixes crashes/ resolution upscaled bugs on certain games that used to have wrong viewporting effect on screen or directly device loss on Vulkan. Adds fixes for regressions caused by previous MSAA refactor on games as Fire Emblem: Engage. Special Thanks 1.- Big Smolio (@Gidoly) Co-authored-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4287 Reviewed-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-by: Samuel <lizzie@eden-emu.dev>
* [vulkan, android] Initial implementation of LSFG-VK (#4263)CamilleLaVey2026-08-171-1/+7
| | | | | | | | | | | | | Pretty much self explanatory, own implementation based on LSFG-VK available with some additional reverse engineer work for the actual use of shaders inside Lossless.dll, we don't store/ bundle any tools that bypass security and self ownership: to use this feature is required to own your own copy of Lossless Scaling and I encourage to support developers behind this work. Special thanks: 1.- THS - Original developer behind Lossless Scaling 2.- PancakeTAS - Developer behind LSFG-VK 3.- The Big Smolio The Sleeper (@gidoly) Co-authored-by: lizzie <lizzie@eden-emu.dev> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4263
* [vulkan] Initial implementation on Bindless Buffer/Descriptors (#4251)CamilleLaVey2026-08-054-1/+139
| | | | | | | | | | Adds a VK_EXT_descriptor_buffer, VK_KHR_device_buffer_address path alongside push descriptors and descriptor sets. The ring is chunked and sized from the device limits, so drivers with a small sampler range (QCOM reports 128 KiB) get more, chunks per frame instead of losing the feature. A pipeline uses one path or the other, never both, since some drivers do not support bufferless push descriptors. The chunk binding is only re-emitted when it changes, and a draw that repeats the previous payload reuses its allocation instead of rewriting it. This whole change will help to reduce the constant use of descriptors on the slower path, improves the "slow implementation" on QCOM drivers (A7xx and older) for push descriptors, improves latency when compiling pipelines. The implementation on indexing descriptors was also refined. _Special Thanks_ 1.- Meowly The Bindless Smol (@Gidoly) Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4251
* [vulkan] Re-adjusting ASTC resolve (#4250)CamilleLaVey2026-08-052-11/+12
| | | | | | | | | | | | | This is an adjustment made due to problems caused by my ASTC changes some pr's earlier; added sanity to decoded blocks, removes the inconditional storage view for ASTC formats (verified against MaxwellToVk logic), added support to VK_EXT_astc_decode_mode which will ensure a better way to resolve RGFA16/RGFA32 on tilers, simplified ASTC HDR decoding into LDR valid formats. This fixes some issues with SteamDeck, Fire Emblem: Engage washed colors and other problems related to ASTC. _Special Thanks_ 1.- Meowly The Smol (@Gidoly) 2.- @simply0001 for the actual idea on the redundant storage views on the transcoded ASTC path. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4250
* [fmt] use {#:x} instead of 0x{:#x} (#4170)lizzie2026-07-251-2/+2
| | | | | | | | | | continuation of #309 but applying to even more files than before :) also makes them lowercase because `0xfafafa` is better as `0XFAFAFA` Signed-off-by: lizzie <lizzie@eden-emu.dev> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4170 Reviewed-by: CamilleLaVey <camillelavey99@gmail.com> Reviewed-by: Maufeat <sahyno1996@gmail.com>
* [vulkan] 4th Vulkan Global Maintenance (#4212)CamilleLaVey2026-07-162-9/+52
| | | | | | | | | | The approach on this PR moves around refactoring/ updating residual work; main issue was the whole logic behind msaa upload/download images with the constant image copy per pass required; which was gated via shaderStorageImageMultisample, which is not available on all the platforms supported including Android, making them to rely into a more heavier approach to convert msaa image copy into a non msaa image copy, not only losing precision in the conversion, but also creating bugs around the resolve of the image itself, if the supported path had to copy 2 times the same image to be actually presentable, when the fallback was enabled 3 copies were performed, not only decreasing the performance but also increasing race conditions due to the certain capabilities processed in this chain (storage_views). In order to resolve them more naturally, the constant copies were removed from the now "common" path along establishing a proper color resolve for Android and actually making them more direct. Yet this opened a new pack of outdated handling on our current backend; since we now pass msaa images more directly (whenever a game request a msaa type of image/ which seems to be not common + each fragment resolves images on how it's actually required, adding missing depth/stencil), how we often load and store them becomes a critical issue, since our current configuration renderpass/framebuffer forces to always load and load clear whenever a new attachment it's passing through the renderpass, making this really heavier on memory bandwidth limited devices as SteamDeck and others that doesn't rely on the inmediate rendering mode (Tilers vs iGPU); to prevent over allocating data, I had to re-structure part of the current renderpass and framebuffer to actually reuse part of the data/ attachments called, with flags as DON'T_CARE, simplifying partially on how we actually call attachments including their barriers and conditions (occlusion, etc), the DON'T_CARE it's specifically useful to not only prevent calling new loads (which is a flush and heavier on tiler devices) and not only reusing the actual data store, which works on the future time, this saves memory bandwidth and gives space to actually avoid the constant pressure on SYSMEM/GMEM shader resolver path. This maintenance also improved the current removal features logic on QCOM drivers, closing gaps between implementations on descriptors (VK_EXT_indexing_descriptor), adjusting the whole WMEL to avoid being so stricter if certain capabilities are missing to actually use this feature, leading to test and play more on how QCOM drivers are actually behaving; meanwhile the main objective is to open path for a robust and bigger implementation in the future, the changes made here also contains small bug fixes on SPIR-V logic, adding missing cases to resolve shaders (FP64 -> FP16), adding more robustness on how narrow features are actually being used and how to wired them whenever they're not available, meanwhile there are still some issues in regards on how Tegra vs Adreno can preserve unorms at FP32 and FP16, leaving better understanding on base for what VK_EXT_shader_float_controls is actually doing most of the times (flushes NaN's and Denorms equally). Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4212
* [vulkan, android] Mediacodec implementation + Vulkan fixes (#4191)CamilleLaVey2026-07-094-1/+51
| | | | | | | | | | | | | | | | | | | This is the first step into the conversion on full GPU video decoding for Android; currently due to the VIC structure, I couldn't set it on surface mode to prevent the latency when sending video decoded (which is processed by GPU now), because currently we convert YUV420 into the Nvidia's format each frame constantly on CPU, aside the requirements from other extensions to work + VIC rewrite, which is a work currently not planned to happen on this PR; the actual configuration for video decoding is ByteBuffer, using GPU to decode NVDEC data (all codecs supported, h264, vp8 and vp9) and send it to CPU for display purposes, which is more faster than relying purely on CPU for any drawing task, saving devices resources/ heating, the downside on this will be the slight latency when a new frame is displayed, which is gonna be a black frame for less than a second, nothing major to harm the experience rather than actually trying our best to take advantage on hardware accelerated. Aside this, I also added a bunch of minor Vulkan fixes to grant drivers less thinkering when receiving spir-v instructions, meaning this has new bans for extensions on QCOM (following reported issues on other projects working around Adreno driver behavior), this more than providing performance aims to enhance the stability on the driver, performance it's gonna likely to be hit based on the UBO's (StorageBufferAccess) operations and SSBO (uniformStorageBufferAccess), there was an already existing path for the emulation which forces to wide them into 32bit packed operations. I also included some smaller changes/ bugs + VUID's fixes from earlier changes on my work. Special Thanks: -> Mr. Smoly Gidolard (@gidoly) Sources: 1.- https://github.com/microsoft/DirectXShaderCompiler/issues/2842 2.- https://github.com/mlc-ai/web-llm/issues/836 3.- https://github.com/ggml-org/llama.cpp/issues/5186 4.- https://github.com/encounter/aurora/pull/202 Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4191
* [video_core] Implementation on ASTC HDR formats + Vulkan fixes (#4190)CamilleLaVey2026-07-091-3/+5
| | | | | | | | | | | | Based on the register of the ASTC implementation from Ameerj (yuzu), currently our conversion from ASTC on Desktop tends to duplicates the unpacking of ASTC converted textures, leading to bad performance; since there are some graphical effects that actually access on the band of 32bits (RGAF32) than the common 16bits (RGAF16) from our ASTC path decoding method, which commonly uses ARGB8 (degradation -> LDR) transformation to reduce the memory cost per conversion; meanwhile it could actually provide initially better performance; the engine tended to get stalled when this writted stage effect got skipped; mostly because CPU tends to look for an unimplemented texture/ format query (from which doesn't exist on our MaxwellToVK); unlike what's commonly believed HDR was a format to write enviroment effects even before their appearance on video output (since Switch doesn't have HDR, only SDR on certain engines). The test result on this PR showed games like Astral Chain and other heavy reliant on ASTC decoding improved their performance and stability by around 15%; meanwhile could it be tied to a hardware gain, it's clearly a gain for direct access on what's required on most games. This PR also contains few Vulkan bug fix I encountered along this implementation. Special Thanks: -> Mr. Smoly Gidolard (@gidoly) Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4190
* [vulkan] 3rd Vulkan Global Maintenance (#4189)CamilleLaVey2026-07-094-24/+173
| | | | | | | | | | Following the philosophy on the previous Vulkan maintenance PR's, this one is reviewing the video_core to resolve VUID's related to the missing handling/ safechecks (UBO's case on missing StorageBufferAccess 8/16 bits on QCOM drivers, resulting on bad compute pipeline compiled), wiring topology representative to EDS2 configuration (following #4117), refactored the sampled image access via new memeber function for type "typeless" which adds a handling on the integer mistmatch (uint to sint, float to uint) + fixing bugs on current texture sampling (int) including the depth/stencil path resolve, maintenance to previous changes on query cache (resolving bugs from #3853), reduced the amount of binding BindVertexBufferEXT2 when a new tick/ frame is presented (with this being a reason for performance reduction on games where vertex polutes the stage, like BOTW/TOTK where grass is draw with vertex); implemented color border swizzle and color write enable for future improvements on EDS3, added initial implementation on Synchronization2 starting a path to ensure an access to VK 1.3 features safely and other smaller fixes along the road. Special Thanks: -> Mr. Smolio Gidolard (@gidoly) Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4189
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-04 01:44:55 +0000