just wondering, Bards Tale

[Jasperfoust]

yeah i can tell it is. tho it mostly only slows down during convo's with npcs. slightly annoying but not game breaking. so far the game is definitely playable. ive come acrossed afew areas while moving around where the fps drops. but so far none during combat. its far from perfect and i believe im playing in software mode. unsure as ive been using f9. but its a HUGE improvement from what it was the last time i tried the game.

[FlatOut]

Ok. Could you do a quick test on native. 3x is maybe too big for this game.

On native I get lower VRAM usage overall, with both 8bit & the hack usage cutting VRAM usages by about 2/3th. But the actual performance is the same as on 3x native.

[willkuer]

@Jasper
F9 is a temporary switch. After restarting emulation it is reverted. Put internal resolution to 2xnative or higher and you will directly see the difference between hw and sw mode.

[gregory]

On native I get lower VRAM usage overall, with both 8bit & the hack usage cutting VRAM usages by about 2/3th. But the actual performance is the same as on 3x native.

ok. Quick bench on my side (8 bits texture, native, BA basic, acurate date and depth)
no hack: MT => 37
hack + MT => 68
hack - MT => 62

I don't understand why you don't get the same speed up on AMD.

[FlatOut]

ok. Quick bench on my side (8 bits texture, native, BA basic, acurate date and depth)
no hack: MT => 37
hack + MT => 68
hack - MT => 62

I don't understand why you don't get the same speed up on AMD.

Me neither, especially because base speed is the same on DX11 as it is on OpenGL, so MT was already unlikely to be the issue, and VRAM usage does reduce with the hack. For all intents and purposes, it should work.

[gregory]

As you can see on my stat. MT isn't an issue. MT doesn't work well with game that need to read the GPU memory anyway.

Purpose isn't to reduce the VRAM as per se. It is a side effect. Game uses a special kind of texture. Texture width is 1024 but the memory buffer is much smaller. You have all kind of mirroring. It creates a huge overhead on GSdx. Because you need to monitor each blocks update/invalidation of each textures. (so you have a busy 3 level loop by draw...).

Hum, we need some people to test the hidden hack on Intel GPU/Driver. Linux test will be nice too.

[Dreadmoth]

@nvidia users

Could you test the hack impact on DX11 too ? Thanks you.

DX11, 3x Native, Allow 8-Bit Textures enabled, MTVU off
Hack off | Hack on

So...

Direct3D11: 35.09 to 53.33 = 51.98% increase

OpenGL (Blending Unit Accuracy "None"): 42.82 to 81.22 = 89.68% increase

---

EDIT: Performance is almost identical on Native vs. 3x Native - with or without the hack, on D3D11 or on OGL

EDIT2: I re-checked Blending Unit Accuracy "Basic" on OpenGL and it performs similarly (or 1-2fps faster) to "None" - something in the background may have slowed it down when I tested before.

[FlatOut]

Hum, we need some people to test the hidden hack on Intel GPU/Driver. Linux test will be nice too.

Intel iGPU has the same results with OpenGL. But while AMD GPU gets a good performance boost with 8bit textures on DX11, with Intel Driver it reacts like it does with OpenGL.

[gregory]

@Dreadmoth
Thanks for the info. It is very interesting. It shows that openGL has less driver overhead than DX. And I didn't spend months for nothign to reduce it. Even if the difference is 0 in most game.

@FlatOut
Maybe it is too much for the poor iGPU.

[gregory]

Wait I have another hypothesis. Could someone test this change on Nvidia. Basically delete the "t->Invalidate();" line from GSDevice.cpp.

Code:

diff --git a/plugins/GSdx/GSDevice.cpp b/plugins/GSdx/GSDevice.cpp
index 23e01d0..c3f054b 100644
--- a/plugins/GSdx/GSDevice.cpp
+++ b/plugins/GSdx/GSDevice.cpp
@@ -184,7 +184,7 @@ void GSDevice::Recycle(GSTexture* t)
        // Invalidating the data might be even worse. I'm not sure invalidating data really
        // help on the perf. But people reports better perf on BDG2 (memory intensive) on OpenGL.
        // It could be the reason.
-       t->Invalidate();
+       //t->Invalidate();

        t->last_frame_used = m_frame;