I doubt a 7600K with a decent OC would bottleneck and even then, BOTW is the only game where I can’t stay pegged at 60 and that’s only out in the open world
I also ran Cemu 1.11.3 in Wine a couple of weeks ago, 3D World ran fine and the only issue was that I couldn’t fullscreen
(I swear that’s actually Linux)
I’ve honestly never even touched Linux.
Looks like Ubuntu or Mint are probably the main choices for gaming? I looked around fairly hard, and could not find any sort of decent collection of info. If someone could recommend version of Linux for gaming and how to get AMD open source drivers, that would be great. I saw a Cemu forum post saying that the graphics rendering is improved for AMD, in Linux. In addition to a bunch of extra performance.
For now, I seem to have gotten rid of virtually all stuttering. At 1080p I can maintain about 27fps as absolute minimum. Most of the time I’m sitting at about 32fps with Link in motion (FPS increases, if you stand still). But many times, its higher around 39fps even in motion. So pretty good.
The final tweaks I made were getting the “fencing” optimization to work properly. and Then I figured out the quirks of the shader caching. In addition to that, I put Cemu (including its cache folders) and the AMD’s own shader cache folders on a RAMdisk (free from AMD’s site). I then created symbolic/hard links in the original AMD shader cache location, pointing to the new RAMdisk location. So that the GPU driver would put any changes onto the RAMdisk.
All of Cemu is on the RAMdisk, except for the folders which contain the patche updates and DLC files for BoTW. Because that’s a few gigs of data. So I put symbolic/hard links on the RAMdisk, pointing to their location on my SSD. So when I load CEMU from the RAMdisk, it is able to find those files even though they are actually on the SSD.
So, with the shader cache files on the RAMdisk, the initial loading of the shaders before BoTW loads, is waaaaaaaay faster. Maybe 8 seconds. And in game, any referencing of the AMD cache, or Cemu’s main files, should be even faster than my SSD. and I think it is. the game feels fluid. Cemu’s cache is loaded into RAM, so I’m not sure if the RAMdisk improves that aspect, in game. But some posts on the CEMU forums suggests that they can’t keep Nvidia or AMD drivers from sometimes using their own caching. So recently, people have been focusing on those folders. So I put it all on the RAMdisk.
If you are interested in giving that RAMdisk idea a try, I used Link Shell Extension to create the symbolic/Hard Links. You can do it in a command prompt, but ehhhh…
I also watched a youtube video of a guy with a similar system i5 6600k and 16gb ram----but with an RX480, which is at least double performance of my 7870. and his framerates were very similar to mine. Which suggests that AMD’s openGL path for CEMU is only good for a certain amount of performance. and that’s it. It apparently has something to do with how the API communicates the GPU and CPU. And CEMU’s overall code path for the GPU emulation, is still single threaded. The recent dual and 3 - 4 threads (in game) features are only for the CPU emulation. Which is why a lot of AMD users still aren’t seeing performance past a certain point. Its a software limitation, creating a CPU limitation to the GPU.
I LIED
good job AMD
seeing as textures in Splatoon are also not rendering correctly and that it’s generally accepted that AMD OpenGL drivers are more conformant to spec, I’m just going to go with “Cemu’s authors are writing against Nvidia cards”
I hear 1030s are cheap
is that a real graphic card
it is, more or less, a laptop part repackaged as a discrete GPU and sold for under a hundred bucks because it hits the magical goal of running esports titles at 1080p decently
it’s slower than a 750 Ti but it’s readily available and has passively cooled models
it’s cute
it’s now the budget winner because even 1050s are being scooped up for mining
I think there are a couple of things going on here.
AMD’s drivers (Windows, official Linux, open source Linxu) are all separate stacks. And until very recently, they even had two different stacks for Windows alone. They don’t have a “unified” approach, like Nvidia does. So there are differences between stacks due to different goals emphasized by presumably different project leads. And my impression is that the current Windows driver is the worst stack of all, for OpenGl. And Cemu devs claim that OpenGL is the only way for them to do Cemu in the way they are doing it. They claim that Vulkan will not necessarily net better results. But Vulkan is planned.
Indeed, I think as far as rendering results are concerned, Cemu is probably focused on recent Nvidia cards. To be fair, recent AMD cards seem to have better rendering quality in BoTW, than my HD7870 which is pretty old, but still relevant. Seeing as regular PS4 is basically a downclocked 7970. And Nividia does have its own set of problems in Cemu. Nvidia Rendering quality is pretty much outright better or fixed via graphics packs. AMD’s is not. Atleast, not for all relevant cards.
Nvidia does have a pretty major RAM leak on a lot of systems. One of the main Cemu/BoTW youtubers pretty much fills his 16gb of system ram when Cemu is running BoTW (maybe other games?). Well, it was like that. The new version out now for payed members, cut a couple of gigs off that usage without extra tweaks. But still, my AMD system uses a hair over 8Gb of system RAM, for BoTW. it has something to do with the way Cemu caches shaders with Nvidia.
Isn’t OpenGL dead yet? Kind of a dated garbage API especially for something like an emulator
emulator devs tend to like it more than others for whatever reason – and, in fairness, for a very long time it was the only alternative to D3D, and emulators really shouldn’t be dependent on windows codepaths (as opposed to big-budget commercial releases for which there’s less justification to target non-windows platforms).
but, I mean, a massive part of these decisions are just down to “what the person who is working on this project has experience with”
though it’s also why Cemu has the unusual distinction of being an emulator that will run better in wine than natively for some people – because the developers haven’t put in the effort for it to build on non-Windows (which is mildly bad karma, given its how unusual its closed-sourcedness already is, though I assume that’s down to SDK code use), yet they wanted to use OpenGL, and OpenGL has a long history of weird implementation differences on different platforms.
anyway, one graphics API is almost never technically more performant than any other, at most it’s a difference in driver overhead, which Wii U emulation shouldn’t quite be pushing anyhow.
also in a literal sense OpenGL is not only not dead, it recently went to 4.6, including some extensions that basically allow it to share state with Vulkan codepaths
https://www.phoronix.com/scan.php?page=news_item&px=Intel-OpenGL-4.6-Out-Of-Tree
probably the actual reason
I sure do love this crime I’m complicit in
That’s not how this works. Yes it’s driver overhead, but the OpenGL contract basically forces the driver to do a bunch of usually-redundant work on every draw call.
I agree about Wii U overhead not pushing it, but the other problem illustrated in the screenshots is that correctness-wise, OpenGL is too complex and rich in a way that is barely scratched by the conformance suite, so there’s a lot of vendor divergence.
The endgame for OpenGL is death in terms of driver implementations and emulation in userspace on top of Vulkan. A shared shader binary format helps with that.
one of the goofiest decisions resulting from OpenGL conformance requirements in recent memory was when Intel actually went to the trouble of hiring a contractor to implement FP64 in their Linux driver, because FP64 is a requirement of OpenGL 4.0/4.1+, even though approximately no one will ever be making use of those codepaths on an Intel GPU since they’re pretty much only needed for GPGPU compute stuff
it’s still a good thing they did it since Intel are functionally a huge chunk of upstream Mesa open source work these days but seeing people (who, mind you, are already highly invested in linux gaming, so they have some screws loose) on the internet really invested in getting their Intel GPUs to report OpenGL 4.5+ in Linux was, uh…
anyway I’m very proud to say that my Haswell notebook reports OpenGL 4.5 compliance in glxinfo
I tried the HD 630 graphics in my 7600k with BoTW via Cemu. The graphics were really screwey. it was like sepia and overbright. Most of the extra shadows were gone and one of the shader passes showed up as a black grid which would move and spread around like a music visualizer or something.
and enabling the GPU fencing hack, would allow it to hit 30fps-----and then it would crash.
*I should mention, I was able to hit 30fps with the HD630, because my ram is fast and I overclocked the HD630 to 1500mhz >_>
well sure but Nvidia’s OpenGL driver is already proactive enough that no one has succeeded in writing Vulkan code that really outperforms it
Hmm, I guess you’re referring to this: https://www.pcgamer.com/doom-benchmarks-return-vulkan-vs-opengl/2/#article-body . I’d be interested to know what’s going on there. I suspect there’s a complicated story behind it.
Maybe Nvidia contorted their hardware to better support the quirks of OpenGL while AMD said screw that nonsense and invented Mantle. Or Nvidia’s OpenCL tech gave it powerful primitives to improve OpenGL performance. Or AMD’s Vulkan driver is better than NVidia’s because they derived it from their Mantle driver. Or all at once or none of those.
it’s pretty widely believed that Nvidia is just more willing to aggressively cache stuff (for many definitions of “cache”) so they can discard redundant calls even when it means not implementing the standard as faithfully, because they have enough $$$ and people to actually do so effectively and not create more problems for themselves
also why AMD was effectively forced to deprecate their old proprietary Linux driver stack and go the Intel route of contributing to Mesa; they don’t have the resources to get away with what Nvidia does
(I realize I’m semi-conflating the state of Windows drivers vs. non-Windows drivers but it’s generally borne out across the board)
That theory is sort of a variant of “Nvidia’s OpenCL tech gave it powerful primitives to improve OpenGL performance.” The thing about caching is that you can’t do it if your code is monolithic spaghetti. You need to segment it into a clear data pipeline with modules with staging areas between them and then you can cache the contents of the staging areas. This kind of well-defined architecture is likely also useful for OpenCL.
those benchmarks don’t say if async compute is on (essentially the 8X TSSAA option), which is a thing Maxwell doesn’t do, Pascal kinda does in a hacky way and GCN actually does properly and thus gets the AA for essentially no cost
anyway, Vulkan is cool. running the Vulkan codepath for Doom in Wine gives pretty near native performance. it’s cool.
obligatory joke about how Nvidia doesn’t implement OpenCL, it implements CUDA
