GSdx 1.0

[gregory]

@brown.nerd
Could you generate me a bigger dump? Take a scene where the issue is really visible. (it is very hard to debug small pixels issue).

@NoleNation, @willkuer
Yes I have lots of issue with Intel driver on windows so I just disable it. Potentially they fixed their driver but I don't think so. However Intel driver on linux is working nicely. But I'm not sure that it would be faster than the Dx driver. If you want to try the linux version, try to get the future Mesa 11.0.

[gregory]

I'm still on zone of ender speed. The slow frame uses 5712 draw calls with a mean of 6-8 primitives by draw. Current API isn't designed to support this high number of draw call. There is a potential future extension that would help to reduce the cost of draw calls. ( https://www.opengl.org/registry/specs/KHR/no_error.txt ). I think it would help to reach the DX level.

[iMineLink]

I'm still on zone of ender speed. The slow frame uses 5712 draw calls with a mean of 6-8 primitives by draw. Current API isn't designed to support this high number of draw call. There is a potential future extension that would help to reduce the cost of draw calls. ( https://www.opengl.org/registry/specs/KHR/no_error.txt ). I think it would help to reach the DX level.

But, how could possibly the PS2 manage to do such a big amount of work? As you said, the game wants to change the render target very often, and makes a lot of draw calls. Could it be that it draws too many things on the top of things instead of using transformation and proper shading?
Can you detect which function of the gsdx ogl plugin are mostly called during a frame?
But still, that's just for the sake of asking, would it be possible to reduce the number of draw calls packing some data before dispatching the work to the gpu (http://unityready.com/aware-static-dynamic-batching/)?

[gregory]

GS isn't a GPU. You don't need validation, you don't need flushing. Actually it doesn't have the notion of draw call, vertices are sent 1 by 1. GSdx will pack them to create draw call.

Can you detect which function of the gsdx ogl plugin are mostly called during a frame?

More or less. Globally the top one are GS emulation and later the draw and RT setup. However due to multi thread, it is hard to analyze the result. Setup of the RT is slow but it isn't called that often. I think the biggest issue is the number of draw calls.

would it be possible to reduce the number of draw calls packing some data before dispatching the work to the gpu

It would be hard to improve the current situation. Potentially a couple of draw calls can be merged but it won't be enough (we need to go below 3000-4000). The less work solution is
1/ wait the no-error context
* It will reduce the cost of draw call and also the cost of setup of vertex/texture/framebuffer.
* It is 5 lines of code to update
2/ investigate GL_NV_command_list
* Basically vulkan/dx12 stuff without a full rewrite of the plugin. It is a rare game that will get an improvement
* However it will consume extra memory on our limited pool

[iMineLink]

GS isn't a GPU. You don't need validation, you don't need flushing. Actually it doesn't have the notion of draw call, vertices are sent 1 by 1. GSdx will pack them to create draw call.

More or less. Globally the top one are GS emulation and later the draw and RT setup. However due to multi thread, it is hard to analyze the result. Setup of the RT is slow but it isn't called that often. I think the biggest issue is the number of draw calls.

It would be hard to improve the current situation. Potentially a couple of draw calls can be merged but it won't be enough (we need to go below 3000-4000).  The less work solution is
1/ wait the no-error context
* It will reduce the cost of draw call and also the cost of setup of vertex/texture/framebuffer.
* It is 5 lines of code to update
2/ investigate GL_NV_command_list
* Basically vulkan/dx12 stuff without a full rewrite of the plugin. It is a rare game that will get an improvement
* However it will consume extra memory on our limited pool

I'm sorry for my ignorance about the GS emulation but I never looked at the code before yesterday, and it's hella complicated, but I'm getting the basics. The no-error context could be quite a speedup then. Or the Vulkan stuff, but it would require some hard work to implement right?
The strange thing is that in that part, if I try to disable 8 bit textures, the emulation saturates my 2 GB vram in a second, otherwise, it occupies just 200MB. That's quite strange for a "almost" cell shading game...
I don't know...thanks for the investigation!

[gregory]

Yes 8 bits texture allow to use index to a table. Instead of a RGBA 32 bits texture. The game uses lots of different texture so the texture cache becomes crazy.

[Brown.Nerd]

this is GIF moving Pic show's the issue

http://www30.zippyshare.com/v/131yKoRP/file.html

This is Dump

http://www30.zippyshare.com/v/9dktIYRU/file.html

[iMineLink]

Yes 8 bits texture allow to use index to a table. Instead of a RGBA 32 bits texture. The game uses lots of different texture so the texture cache becomes crazy.

LoL cannot wait to see further developement of the plugin
Keep doing good!

[Dr_Hycodan]

Is it just me or does software rendering run faster on Windows 10? I used to get a lot of micro stuttering with Ace combat 5 and zero, especially on rendering new scenery, but now on windows 10 they both run perfectly smooth. Is there any way to fix this to run smooth on Win 8?

[refraction]

Windows 10 has probably improved multithreading, so that might be why it's smoother