Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[GSdx GUI] Clutter in the renderer dropdown menu
#1
Now, this isn't exactly an emulator/game breaking bug or anything, it's more like a minor tidbit that I think could be done better.
It is my understanding that pcsx2 can process and render images to the screen using 4 APIs - Direct3D 9, Direct3D 11, OpenGL and OpenCL - which enable the usage of GPUs to accelerate the rendering.
In addition to that, pcsx2 can also draw to the screen without them i.e. all the image procesing is done on the CPU and this is called "software mode".
Finally, pcsx2 can just not draw at all, the equivalent to writing to /dev/null in Unix, and that's just called Null.

This is a total of 6 distinct choices. In the pcsx2 GUI, while using GSdx as a plugin, if we go to "Config > Video (GS) > Plugin Settings..." and check the "Renderer" drop-down menu, we have this:

   

We're offered 14 options to choose from. I like options, but aren't 8 of them non-sensical? Surely pcsx2 does not emulate Direct3D 9 on the CPU...because that's what I infer from the "Direct3D 9 (Software)" option. I understand that in practice this is just another option that uses the software renderer.
And surely pcsx2 doesn't emulate OpenGL instructions using OpenCL, because that's what I'd say the "OpenGL (OpenCL)" would do.
So why doesn't that GUI bit look like this instead:

   

If these types of threads don't belong here, give me a heads up so I don't do it anymore. And if I'm wrong, please do correct me.
Reply

Sponsored links

#2
(10-21-2015, 12:21 AM).r5 Wrote: If these types of threads don't belong here, give me a heads up so I don't do it anymore. And if I'm wrong, please do correct me.

I would have put this thread in "Plugin Discussion and support", but whatever. Assuming mods here are able to move threads, they will probably do so.
Reply
#3
This would potentially be better and also would make more sense to have one null and software renderer over 3 of them. this should be no problem to implement, I'll consider writing code for this after #904 get's merged and if everyone agrees to the following format. and I'm not really sure why OpenCL is even still there ...

*Moved to General Discussion and Support Forums*
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction

[Image: 84t1dRu.png]
Reply
#4
There is a software renderer for each API simply because there is a software renderer that runs through all 3 API's Tongue

I agree there should only be 1 entry for Null however, but the others all should rightly have Hardware and Software modes. OpenCL shouldn't even be there really as it's not enabled.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#5
(10-21-2015, 01:28 AM)refraction Wrote: There is a software renderer for each API simply because there is a software renderer that runs through all 3 API's Tongue

I agree there should only be 1 entry for Null however, but the others all should rightly have Hardware and Software modes. OpenCL shouldn't even be there really as it's not enabled.

I still don't understand. What's the difference between D3D9 (SW), D3D11 (SW) and OGL (SW) other than:
0) The name;
1) The F9 key toggling a different hardware renderer;

What's the concern here? Object inheritance problems?
Reply
#6
It uses the different API, so dx9 software mode uses dx9, dx11 is dx11, and ogl is ogl.

The dx software renderer's for example do not function in Linux.
Intel Core i5-4690k @4.5ghz
Samsung 16GB DDR3 @2000mhz
GeForce GTX 1080 8GB
Windows 10 x64
Reply
#7
(10-21-2015, 04:26 AM)hellbringer616 Wrote: It uses the different API, so dx9 software mode uses dx9, dx11 is dx11, and ogl is ogl.

The dx software renderer's for example do not function in Linux.

This, although in software mode most of the work is done on the cpu, the output is still pushed through its related API.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#8
(10-21-2015, 06:26 PM)refraction Wrote: This, although in software mode most of the work is done on the cpu, the output is still pushed through its related API.

Meaning the last instruction is an API-specific draw function, right? Can't you let WxWidgets, SDL2 or Qt automagically do that for you?
Reply
#9
i dunno if Wx or Qt can do it, we've already removed SDL once, we don't wanna put it back in ;p

But it's good to have variety unless it's a problem with the API itself.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#10
(10-21-2015, 07:19 PM)refraction Wrote: i dunno if Wx or Qt can do it, we've already removed SDL once, we don't wanna put it back in ;p

But it's good to have variety unless it's a problem with the API itself.

I might be coming off as hard-headed, apologies if so, but why would it be good to have that much variety?
When using D3D9(SW), D3D11(SW) and OGL(SW), work related to processing a frame is done entirely on the CPU. Only when the frame is done do you call one of those APIs to fill in video memory and actually draw it (correct me if I'm wrong).

Why maintain that at all? Just use the most crossplatform way of doing it (OGL?), or rely on whatever framework you're already using (WxWidgets). I'm assuming filling video memory and doing draw calls when the CPU is doing most of the job costs the same regardless of what graphics API you're using.
If this is a no-go, at least change the renderers names around, so there's less of them and it's clearer to a newcomer.
An example:

Code:
Direct3D 9
Direct3D 11
OpenGL
Software (OpenGL)
Software (D3D9)
Software (D3D11)
Null
Reply




Users browsing this thread: 1 Guest(s)