Gsdx future discussion

[BlackTelomeres]

I don't think the DX11 backend is truly deprecated, either. At least not until we have DX12 or Vulkan. It's true gregory only works on OGL, but that's mainly because of his linux roots. At least some of the recent fixes have been ported to DX11 by refraction(like snowblind)

Deprecating DX11 for DX12 is essentially removing support for any Windows lower than Windows 10.

[refraction]

At least some of the recent fixes have been ported to DX11 by refraction(like snowblind)

Ported is a strong word, hacked in by copying is probably more accurate

[Blyss Sarania]

Deprecating DX11 for DX12 is essentially removing support for any Windows lower than Windows 10.

Not really. It's still available in legacy plugin, it just means it's not being worked on. Just like DX9 situation is now. The problem is DX11 lacks some features that we need for accurate emulation. That's the other reason why it's behind OGL - it's not just that we have no one to work on DX11, but that it's significantly more difficult to do some of the things we need to do in DX11. DX11 isn't suddenly going to get those features either, so yeah it sucks but it's really not our fault. We can't make Nvidia or AMD or Microsoft or anyone do stuff. They support stuff as they see fit. We are a small team, we definitely don't have the manpower to fill the gaps that they left behind.

@refraction - lol

[BlackTelomeres]

Not really. It's still available in legacy plugin, it just means it's not being worked on. Just like DX9 situation is now. The problem is DX11 lacks some features that we need for accurate emulation. That's the other reason why it's behind OGL - it's not just that we have no one to work on DX11, but that it's significantly more difficult to do some of the things we need to do in DX11. DX11 isn't suddenly going to get those features either, so yeah it sucks but it's really not our fault. We can't make Nvidia or AMD or Microsoft or anyone do stuff. They support stuff as they see fit. We are a small team, we definitely don't have the manpower to fill the gaps that they left behind.

@refraction - lol

What would that mean for the ability of devs to "hack in by copying" () some new things that DX11 could handle though?

[Blyss Sarania]

What would that mean for the ability of devs to "hack in by copying" () some new things that DX11 could handle though?

Well the code wouldn't disappear - they'd still be able to do it. But it generally wouldn't happen unless it was something really important.

But the other thing I forgot to mention is we aren't going to have a DX12 backend for a good long while unless Gabest just pops up and does random magic. But as things stand now we are much more likely to get Vulkan first, and even that is quite a ways off according to gregory.

So it's not like it would be deprecated tomorrow. Think more like in a year or more.

[gregory]

For what concerns the first topic I totally agree with your viewpoint, and furthermore I think that you could try and push further your work by making a new "GSogl" plugin pruned of all the DirectX code, where you can more freely fine tune the code and reduce codepaths lenghts where possible. I mean, the development of the OGL renderer has reached higher level of compatibility and stability than the DirectX one, and the higher speed (in some games, with specific drivers) of the DirectX renderer is not worth (imho) keeping an almost discontinued branch of the plugin alive in a new version.
For what concers the second topic instead I don't see the need for custom resolution (3x does the job on FHD screens) or AA filtering (bilinear is just fine).
I have other questions regarding the future of the plugin (don't want to go OT too much, you can simply not answer if you don't want to derail the thread):
1) Will mipmapping be implemented in the OGL HW renderer in the future? (I know there are some huge obstacles)
2) How about implementing a system of draw call batching? I mean the current state of things is more or less "set the state, load geometry, load the texture, draw the texture", for every texture in the scene (which is the original way PS2 worked, with capable streaming hardware). Would it be possible to do something like mapping geometry and textures data to states, while keeping them in main memory, mantaining the map sorted by state, and when a certain quota of mapped entities is reached, commit the multiple draw call to the GPU, changing the state only when needed. You know better than me what I'm speaking about...it could require some work, but it could deliver great speedups.

On linux there is no DX backend The backend isn't critical. It doesn't impact too much openGL anyway.
1) mipmap, I don't know. Which make me think that pure integer coordinate is maybe not the best solution. However I'm not sure people really want mipmap in the HW renderer. Maybe we could just fake it.
2) You're right I already think about it. However it would be a ton of work. And I'm not so sure about the speedup. It would reduce driver work but
* It would increase GSdx work
* It would increase GPU work
Latest improvements increases GPU load. And I'm sure future work will increase the GPU load again. Currently the driver runs in a separate thread (well for Nvidia). It is maybe not the slowest part.

Ported is a strong word, hacked in by copying is probably more accurate

Me too, I want to know what you've done for snowblind engine

What would that mean for the ability of devs to "hack in by copying" () some new things that DX11 could handle though?

So far, I try very hard to make some fixes available on DX11/DX9 too. But I think few bugs remain in DX that could be fixed without using "new" GPU capabilities

Well the code wouldn't disappear - they'd still be able to do it. But it generally wouldn't happen unless it was something really important.

But the other thing I forgot to mention is we aren't going to have a DX12 backend for a good long while unless Gabest just pops up and does random magic. But as things stand now we are much more likely to get Vulkan first, and even that is quite a ways off according to gregory.

So it's not like it would be deprecated tomorrow. Think more like in a year or more.

So far, DX12 and Vulkan ports are far from the magic bullet. They got a hard time to achieve the same perf on GPU as DX11... Sure CPU overhead is smaller, but is it really the issue. It seems various people uses DX9 because it is lighter on the GPU.

[refraction]

1) mipmap, I don't know. Which make me think that pure integer coordinate is maybe not the best solution. However I'm not sure people really want mipmap in the HW renderer. Maybe we could just fake it.

I was wondering about that a long time ago, if there was a way to avoid all the mipmap calculation and always use the largest texture regardless, it might cause shimmering but at least it will be the right texture and should be easier to implement than real mipmapping. Failing that, it's using automatically generated mipmaps and somehow translating to use those.

Me too, I want to know what you've done for snowblind engine

What bit have I done for that? lol, I don't think I really did anything on GSDX at least.

So far, DX12 and Vulkan ports are far from the magic bullet. They got a hard time to achieve the same perf on GPU as DX11... Sure CPU overhead is smaller, but is it really the issue. It seems various people uses DX9 because it is lighter on the GPU.

I think the biggest selling point for Vulkan for us currently is the performance on AMD cards. OpenGL is great and is a huge leap for GSDX, but AMD's suffer in speed greatly due to the poor drivers, Vulkan performance would be at least level amongst AMD and Nvidia cards across both Windows and Linux. Beyond that it doesn't bring us much advantage, but would it require a lot of development time? or could we easily translate the OpenGL code to Vulkan? (I realise the 2 are not the same, but there is a lot of talk about developers moving from OpenGL to Vulkan so I presume there is a degree of simularity)

[gregory]

I was wondering about that a long time ago, if there was a way to avoid all the mipmap calculation and always use the largest texture regardless, it might cause shimmering but at least it will be the right texture and should be easier to implement than real mipmapping. Failing that, it's using automatically generated mipmaps and somehow translating to use those.

Yeah something close to it. As far as I understand to optimize GS transfer only the useful layer is uploaded to the gs mem. Gabest implements a vertex trace so you have a range of most the parameters (min/max of position/color/etc...). Maybe we can infer that rendering will sampling only the layer 2 to 4. This way, maybe we could just upload the texture layer 2.

I think the biggest selling point for Vulkan for us currently is the performance on AMD cards. OpenGL is great and is a huge leap for GSDX, but AMD's suffer in speed greatly due to the poor drivers, Vulkan performance would be at least level amongst AMD and Nvidia cards across both Windows and Linux. Beyond that it doesn't bring us much advantage, but would it require a lot of development time? or could we easily translate the OpenGL code to Vulkan? (I realise the 2 are not the same, but there is a lot of talk about developers moving from OpenGL to Vulkan so I presume there is a degree of simularity)

The thing is
* AMD is slow because it misses threading optimization
* Vulkan is low level so below the layer that does the threading optimization (so no threading optimization either)

Conclusion the first step of a port will be to do the threading optimization. But in this case, I'm nearly sure that AMD driver will be closer of the Nvidia performance. There is still the Intel issue on windows, we need to shot the guy that think that people will upgrade their CPU to gain openGL +1.

[gregory]

but would it require a lot of development time? or could we easily translate the OpenGL code to Vulkan?

To complete my previous answer. Vulkan add lots of overhead to draw a single rectangle. You need to manage the memory, command queue, state, multithread yourself. Once you've done that the port will be pretty straightforward. Just a full rewrite of the shader code to SPIR...

I'm in favor to wait that community build library to handle memory/command queue/GLSL <=> SPIR. Besides I won't be able to maintain 2 backends (I barely manage one). In the meantime we could fix the GSdx front-end bug. And why not add a multi-thread layer.

[BlackTelomeres]

However I'm not sure people really want mipmap in the HW renderer. Maybe we could just fake it.

It wouldn't benefit me but I know some people would want some kind of mipmapping support in the HW renderer so they can play Ace Combat 5 in higher resolution without the landscape turning to garbage blocks. Unless I'm confused in what causes that and mipmapping wouldn't fix bugs like that, but I've heard that problem is due to mipmapping. If there's a severe performance penalty (even in games without the need for it?) I guess you could make it something the user could turn off and on depending on if they needed it in that game just like it is in software mode right now.

I don't see a lot of other games that have bugs due to no/improper mipmapping though so maybe it wouldn't be high priority.