Testers needed for refactoring of texture decode/upload code

[Metzelmaennchen]

(01-17-2011, 06:46 AM)JamesDunne Wrote: [I think I can tackle that one. The biggest problem is we don't know ahead of time where textures are in the ROM to preload them. Then, how do we uniquely identify textures to look up in the preloaded cache when they are presented to the renderer? Furthermore, who's to say a texture address,
SNIP....

I have based this on the thought that the content have to be streamed from disc and therefore somehow have an address which is related to this one here tex.texImage3[i&3].image_base) << 5.
Easy talk... load disc on startup, parse all contents and upload texs to gfx mem.
Afterwards if requested from disc patch adress x with y and so on...
The dynamic textures would be generated after this stage, so just flag them and give them a live timer...
But sorry for my stupid question... should have digged a little bit more into the code and find this out on my own. THX for the explanation
But at least the shader thingy should be useful

[neobrain]

Textures which are loaded from disc only once don't cause that much slowdown/stuttering anyway (esp after the recent sse optimizations), it's mostly the dynamic ones I'd guess.

[Metzelmaennchen]

Done a test run Epona is blue also the mountains. See attached Screeny

Also I have to admit that it runs actually a lot smoother! For example the Wind Waker intro (my favorite benchmark ).

[StripTheSoul]

Gosh, even Dolphin would benefit if we finally got time travels working!

[Metzelmaennchen]

(01-14-2011, 04:00 PM)JamesDunne Wrote:

• decodes the GC/Wii texture onto a temporary memory buffer in RGBA format
• locks the DX9 texture memory
• converts RGBA to BGRA on-the-fly while writing to the DX9 texture memory
  

Couldn't you save some conversion steps (Wii -> RGBA -> BGRA) by using the OpenGL decoder (oh no sse stuff has to be ported )? At least the returned texture formats are pointing to bgra...
Then you just upload the tex to memory without 'on the fly decoding'.
Also this members could be removed
decodeJob.rgbaOnly = g_ActiveConfig.backend_info.bUseRGBATextures;
simplifying the job because you don't have to decide between two render formats for dx <> ogl.
BTW. with glTexImage2D we scored at around 0.85GB/S with nv driver 260 (1.9gb/s with 190 ??). PBOs boosted this to 2.0GB/S
Aren't 0.8 not enough If you like, I could fill in your pbo TODOs in the Ogl part.

[neobrain]

No, we ideally should use the most compact destination format possible in TextureDecode rather than decoding everything to BGRA or RGBA or whatever. That's why that rgbaOnly variable was introduced for in the first place - to have dx11 decode everything to rgba but leave the more efficient VRAM transfers to DX9/OGL.

[Metzelmaennchen]

(01-19-2011, 12:02 AM)NeoBrain Wrote: No, we ideally should use the most compact destination format possible in TextureDecode rather than decoding everything to BGRA or RGBA or whatever. That's why that rgbaOnly variable was introduced for in the first place - to have dx11 decode everything to rgba but leave the more efficient VRAM transfers to DX9/OGL.

I don't get you here I'm not talking about converting everything (I have seen the comment: to save memory, don't blindly convert everything to argb8888...)!

As James stated his hybrid decoder (for DX9) should do a conversion to rgba and afterwards while copying it to gfx memory converting it to bgra.
For these steps I don't see a reason for doing the rgba conversion in between? It's just a buffer in RAM which shouldn't care about format things. And the result is always the same at the end (bgra).

According to what you say and how I understand it, the OGL and DX9 should use the same decoders and only dx11 differs because of using rgba, correct?
Because for DX9 in main.cpp clearly the RGBA path is activated....
Sorry to dig in your code but it's a very fascinating piece of software

[neobrain]

idk who changed dx9 to only use rgba textures, that was just plain stupid.
All backends support different kinds of formats, so each one would have separate paths (with some shared stuff, obviously).

The rgba->bgra conversion would obviously be removed as well then, but whatever..

[Metzelmaennchen]

(01-19-2011, 02:07 AM)NeoBrain Wrote: idk who changed dx9 to only use rgba textures, that was just plain stupid.

Was introduced with r6450...but I won't speak out the devs name

[neobrain]

If you look at the changes in TextureCacheBase.cpp, you'll see that dx9 had already been using rgba textures only before that commit.
I know who it was but.. I won't speak out the devs name ;P (nope, not me)