GSdx 1.0
Are you sure that it isn't latest GSdx version that run smoother. Gabest greatly reduces the memory consumptions. Otherwise another possibility is low power management. I have the feeling that it takes some times to wake up a thread if the CPU fell asleep Tongue2

@iMineLink
Your dump is quite interesting. Main issue is the draw command, if I don't draw anything I have a factor 2-3. However it still slow (i.e. below 200fps), so there are others overhead. It seems the setup of constant buffer cost me 5-10 fps. Maybe it can be improved in the future. It would be so much easier with an open source driver, this way I could directly see which validations are costly.

I read the spec of GL_NV_command_list and it seems to rely massively on bindless feature which is NV only (fermi, even kepler for texture). Anyway it is low priority on my todo list Wink
Reply

Sponsored links

Are GS dumps needed for the messed up shadow volumes in the Jak games that are mentioned in this post on github?
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply
Only if it isn't fixed with the high level of blending accuracy.
Reply
Jak II GS Dumps for Shadows

Here's OGL HW

GS Dump


Here's Software

GS Dump

Settings

[Image: GSDXsettings.png]
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply
Is there any way you can post a screenshot of the issue?
Reply
(08-14-2015, 02:30 PM)Dr_Hycodan Wrote: Is there any way you can post a screenshot of the issue?

The GS dump has a bitmap showing the issue.
[Image: gmYzFII.png]
[Image: dvedn3-5.png]
Reply
(08-14-2015, 10:56 AM)gregory Wrote: @iMineLink
Your dump is quite interesting. Main issue is the draw command, if I don't draw anything I have a factor 2-3. However it still slow (i.e. below 200fps), so there are others overhead. It seems the setup of constant buffer cost me 5-10 fps. Maybe it can be improved in the future. It would be so much easier with an open source driver, this way I could directly see which validations are costly.

I read the spec of GL_NV_command_list and it seems to rely massively on bindless feature which is NV only (fermi, even kepler for texture). Anyway it is low priority on my todo list Wink
Too bad Nouveau is a joke...do you have Intel GPU? their Linux graphical drivers aren't OS? I have Intel integrated GPU (never used LOL) and I can help too if you give me some directions Smile 

The GL_NV_command then is not the way, it would make the plugin less sustainable...
Reply
I won't call nouveau a joke. However I need a fast driver to detect the real slow path. If the driver is slow, all paths will be slow. So far only Nvidia drivers is really fast and I don't have an intel GPU.

Anyway I need to search which parts are slow (except the draw command of course).
Reply
(08-15-2015, 12:24 PM)gregory Wrote: I won't call nouveau a joke. However I need a fast driver to detect the real slow path. If the driver is slow, all paths will be slow. So far only Nvidia drivers is really fast and I don't have an intel GPU.

Anyway I need to search which parts are slow (except the draw command of course).

I didn't intend to insult Nouveau developers, but Nvidia makes them impossible to do a 100% functional driver... Their work is impressive and inspiring for OS community though...
I'm looking forward to search a profiler (if there exists one) for intel gpu driver under linux and do some benchmarking...
Reply
Use perf with mesa debug symbol installed. Potentially I found another root cause of the slowness: texture upload. I only look at palette update 500k update for only 170 frames. I didn't check main texture.
Reply




Users browsing this thread: 2 Guest(s)