You are not logged in.

Read the FAQ and Knowledge Base before posting.
WiFi not emulated and not supported!!
We won't make a 3DS/2DS emulator.



#1 2017-11-06 08:22:29

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 223
Website

what is the bottle neck with desmume at larger resolutions and opengl?

seems desmume is the only emulator that has issues with larger resolution that i know of.  n64, dolphin, ps2, and ps1 dont have these slow down issues at high resolution when a fast computer and a good GPU is behind it.

but desmume at x5 can become quite slow even with jit.  even with a 1080 ti extreme its still slow at x8.

So what causes this slow down if opengl offsets graphics to the gpu.

I should also mention frames drop at higher resolutions when no frame drops have been enabled.

Offline

#2 2017-11-06 16:30:47

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 4,663

Re: what is the bottle neck with desmume at larger resolutions and opengl?

haven't we been over this before? desmume does a lot of processing on the CPU still.

Offline

#3 2017-11-06 18:05:48

rogerman
Member
Registered: 2011-06-04
Posts: 351

Re: what is the bottle neck with desmume at larger resolutions and opengl?

All those systems you just mentioned (N64, Gamecube/Wii (Dolphin), PS2 and PS1) are naturally 3D systems, which makes it much easier for them to run all their graphics natively through a modern PC's GPU. For those emulators, a good GPU always has a lot of influence over the overall emulator performance.

However, an NDS is naturally a 2D system that just so happens to have a 3D subsystem attached to it. Therefore, the 3D subsystem can easily be run through a modern PC's GPU, but the overall 2D-based graphics system must still be run through the CPU. For DeSmuME, a good GPU might have some influence over the overall emulator performance, but this is purely dependent on how individual games decide to use the NDS hardware. Some NDS games make a lot of use of the 3D subsystem, and others make very little use of it. And then there are other games that make no use of the 3D subsystem at all, relying purely on the 2D parts of the NDS hardware.

DeSmuME runs its 3D subsystem in parallel with the 2D system, and then reads out of the 3D layer only when necessary. Therefore, the CPU can be a potential bottleneck if the 2D runs slower than the 3D. It is also possible that the GPU could be a potential bottleneck if the 3D runs slower than the 2D. But in practice, the 2D system usually runs slower than the 3D subsystem, making the CPU the bottleneck more often than not.

And finally, the 3D subsystem can be run through either SoftRasterizer (a purely CPU-based 3D renderer) or OpenGL (a CPU+GPU-based 3D renderer). Obviously, if the user uses SoftRasterizer, that will consume massive CPU resources. But if the user uses OpenGL, that doesn't automatically assume that ONLY the GPU is being used. It still takes some CPU processing to feed NDS data into formats that OpenGL likes. Not only that, but the NDS can change rendering states for every polygon, which incurs a CPU-expensive OpenGL state validation each time this happens. In fact, some games do this per-polygon state changing so much that OpenGL's own state validation makes OpenGL run just as slow as SoftRasterizer!

So in short:
1. The systems you mentioned are naturally 3D systems, which makes the GPU have more influence over the overall graphics processing performance. However, the NDS is naturally a 2D system with a 3D subsystem attached to it, making the GPU have less influence over the overall graphics processing performance compared to other consoles.
2. Individual games can utilize how much or how little they use the 2D or 3D parts of the NDS hardware, making the GPU have a variable influence over the overall performance. In practice, the CPU will be utilized more than the GPU in the vast majority of games.
3. Running the 3D subsystem using the OpenGL renderer is not CPU-free because there is still quite a bit of CPU processing involved in OpenGL.

Offline

#4 2017-11-07 08:53:32

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 223
Website

Re: what is the bottle neck with desmume at larger resolutions and opengl?

ah ok i see now.  yeah now that zeromus mentions it i think i did ask this question before under a topic that didnt have much relation to the question  but it was awhile ago so i had forgotten that id asked.

So one more question is there any chance with future development on desmume that it will become faster in openGL mode using higher resolution's? or has it reached its limit and will depend on when cpus become more power as newer technology is developed?

Offline

#5 2017-11-07 20:22:08

rogerman
Member
Registered: 2011-06-04
Posts: 351

Re: what is the bottle neck with desmume at larger resolutions and opengl?

fintogive wrote:

So one more question is there any chance with future development on desmume that it will become faster in openGL mode using higher resolution's? or has it reached its limit and will depend on when cpus become more power as newer technology is developed?

For rendering the 3D layer itself, it is possible to make some general performance improvements for the OpenGL renderer by improving texture loading times. A couple of things that could be done are:
- Unpacking textures on the GPU rather than the CPU
- For Texture Desposterization and Texture Upscaling, running these filters on the GPU rather than the CPU

Note that these texture loading improvements aren't affected by resolution, but can still help by reducing CPU load. However, most games (but not all) are well-behaved in that they load all their textures all at once, and so DeSmuME caches these textures so that the user usually never notices the texture loading times anyways. This improvement really only helps with ill-behaved games that thrash textures often.

There aren't any more improvements that could be made in minimizing OpenGL state changes -- they are optimized as best as can possibly be, especially in OpenGL 3.2, where all state changes that could possibly be moved to the shader are copied all at once at the beginning of the render.

If there is any improvement that could possibly made that would be directly affected by resolution, it would probably be improving the shaders that emulate the NDS hardware. But even if these shaders were to be optimized to their very best, I don't foresee a lot of performance gain due to the fact that the shader itself is relatively simple.

Any major performance improvements that OpenGL could make that would be noticeable at high resolutions is by moving as much of the 2D graphics emulation to the GPU. However, this would require a major rewrite of the entire graphics system. This would essentially be a research project unto itself, because there are many aspects of the NDS 2D emulation that MUST be processed on the CPU (such as any interactions with emulated VRAM). Not only that, but we would have to emulate the NDS scanline-based compositing on a GPU that wants to work with entire framebuffers. In fact, the way the NDS works with 2D graphics is completely foreign to how GPUs actually work, and so I'm not too sure about how much work can be moved from the CPU to the GPU. Well... it would be a research project.

So in short:
1. Has the OpenGL renderer reached its limits in terms of performance? No, there are still some minor improvements that could be made. However, those improvements would be relatively small, and those improvements wouldn't even be noticeable in many games.
2. Would a better optimized OpenGL renderer significantly improve performance at higher resolutions? Yes, but it would only be a small improvement, since the OpenGL renderer is already very well optimized as it is. (Despite what people might think, emulating the unique NDS 3D graphics hardware is no easy feat on a GPU that doesn't work the same way an NDS does, which causes 3D performance to be lower than it should be.)
3. If portions of the 2D graphics system were emulated on the GPU rather than on the CPU, would that improve overall graphics performance? Yes, and it would be a very significant performance improvement were this to happen. However, this requires a major rewrite of the entire graphics system, which is not reasonable to do during this release cycle.
4. Are more powerful CPUs required for improving graphics performance, especially at higher resolutions? Yes, and having a strong CPU is always going to be a hard requirement for emulating the NDS graphics system any reasonable accuracy. No matter how much emulation work we push to the GPU, there will always be work that MUST be done on the CPU. Having the fastest CPU possible will always be the most important point when trying to run higher resolutions.

Offline

#6 2017-11-11 05:11:08

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 223
Website

Re: what is the bottle neck with desmume at larger resolutions and opengl?

ok thank you for the explanation on everything.  one other quick question i heard some time ago that desmume would possibly be able to dump textures from decompressed game data.  as in dump texture of whatever map model or course is currently loaded in to ram.

Offline

#7 2017-11-11 20:29:33

rogerman
Member
Registered: 2011-06-04
Posts: 351

Re: what is the bottle neck with desmume at larger resolutions and opengl?

Texture dumping will not happen in this release cycle.

When texture dumping comes along, it will exist as a byproduct of a new custom texture replacement feature that will be coming in a future release.

Offline

#8 2017-11-11 23:57:31

fintogive
Member
From: USA
Registered: 2014-04-11
Posts: 223
Website

Re: what is the bottle neck with desmume at larger resolutions and opengl?

Ah ok. nice texture replacement just like in dolphin.  im looking forward to that tongue

Offline

Board footer

Powered by FluxBB