Gsdx future discussion

[Blyss Sarania]

The difference between Nearest and the Bilinears is likely valid. The GPU is doing more work, using a bilinear filter instead of a much lighter nearest one.

But yeah Bilinear(PS2) applies nearest filtering normally, and bilinear when the game requests it. This is what the PS2 does. So it could be none, some, or all textures it requests it on. Bilinear(forced) forces bilinear on ALL textures regardless. So the forced setting should be heavier in almost all cases, maybe the same in some outlier cases. But it shouldn't be lighter which is why I said this game must request bilinear on everything(You said it was XS2? That likely makes sense then).

You could perhaps test another game if you have the free time, it will likely show differently.

[gregory]

It is potentially more complicated. There is a lots of parameters. Anyway, I'm fine with the result. 8 bits texture + bi linear is around 10% on the GPU perf impact. SW texturing will likely be close of 10% too.

[gregory]

I pushed 2 commits to optimize texture memory transfer in openGL. Quick benchmark show a 5%/8% increase in perf (native so CPU limited). It is always welcome

I would need some tests on AMD/Intel GPU with an hidden option.

Code:

ogl_texture_storage = 0

vs

Code:

ogl_texture_storage = 1

For AMD the ideal will be a test of both APU and dedicated GPU.

[FlatOut]

I did a very quick test with two games and definitely saw a bigger increase in performance with Intel iGPU than AMD GPU. 1-2% on AMD, 3-5% on Intel.

[gregory]

Which option is faster?

[FlatOut]

Which option is faster?

ogl_texture_storage = 1

[gregory]

Ok. Time to drop the option

[iMineLink]

First topic: Drop old renderer

Second topic: Support integral texture coordinate

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.

[Ōkami Amaterasu]

GSogl just doesn't have the same ring to it

[Blyss Sarania]

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)