[PATCH] Optimization work on EFB > RAM

[kirbypuff]

This is just what we needed. EFB -> RAM is extremely slow, even on 'monster' PCs

How about implementing postprocessing (HLSL) shader support for the Direct3D9 and Direct3D11 plugins to get them on par (feature-wise) with the OpenGL plugin?

[neobrain]

If you feel like implementing HLSL PP shaders, go ahead. I certainly regard this "feature" (it really is just a toy IMO) as to useless one and thus won't implement it. Some other devs agree with me here and most of the other gfx devs don't even have the time to implement it.

---

Hm, that patch actualy breaks EFB->RAM for me. If I apply it, coins in nsmbw aren't spinning anymore...

---

Fwiw, I don't even understand how the patch should work anyway..
"glReadPixels(x, y, width, height, GL_RED+n, type, componentdata);" <-- this will fill the array componentdata with exactly "width" __bytes__ containing the red channels. on the next calls, this data will just get overwritten with the green and blue channels and finally with the alpha channel o_o

[mudlord]

My test cases work. So I don't know about your issue.

As for how it works, if you bothered to read, each component is read iteratively, one after the other, to build up the image buffer. And then its copied to the normal GL memory pointer, and the other is free'd.

I'm quite willing to improve the implementation, and I am all ears if you are willing to give advice on it too.

[neobrain]

Well, skid also told you that nsmbw doesn't work with EFB to RAM with your patch anymore (coins aren't spinning).

Anyway, let me point out what I think is wrong about your optimization:
"glReadPixels(x, y, width, height, GL_BLUE-n, type, componentdata);
memcpy(pixels, componentdata, componentdatasize);"
We want the pixels buffer to contain data this way: ABGRABGRABGRABGR... (width*height*4 bytes) (ignoring the component order)
HOWEVER, the first (n=0) glReadPixels call will store the data in this format: BBBBBBBBBBBBBBBB... (width*height bytes), which is certainly NOT what we want.
..
Also, I really don't understand how you're expecting the memcpys to work, you're memcpy'ing four times to the same pointer position (pixels) with the same data size (componentsize), so you'll overwrite the data of the first three memcpys anyway..
Sorry, but that patch is totally useless :/ What are your "test cases" anyway?

btw a little off-topic:
http://www.opengl.org/registry/specs/ARB/texture_multisample.txt <-- I think this could help us speed up multisampling in ogl a bit, since with this ext we don't need to resolve the EFB buffer to a non-multisampled buffer each time it is accessed in any way.

[mudlord]

Quote:What are your "test cases" anyway?

Excuse me, but I have tested the patch on Luigi's Mansion (which uses EFB) and Super Mario Sunshine. Both games, I noticed no breaks. Funnily enough.

Quote:We want the pixels buffer to contain data this way: ABGRABGRABGRABGR... (width*height*4 bytes) (ignoring the component order)
HOWEVER, the first (n=0) glReadPixels call will store the data in this format: BBBBBBBBBBBBBBBB... (width*height bytes), which is certainly NOT what we want.

Thank you for talking to me like a 3 year old. I do appreciate it. I'll also keep it in mind.

Quote:I think this could help us speed up multisampling in ogl a bit, since with this ext we don't need to resolve the EFB buffer to a non-multisampled buffer each time it is accessed in any way.

And why would I want to associate with you after you directly insulted me?

[NaturalViolence]

Both of you:

[mudlord]

You butt out of this. This is between Neo and I.

[Trevor_Z]

Holy crap, what an ass. It's almost like every single message he posts here has to fill an insult quota.

You know what? That chill pill?

Take two.

[StripTheSoul]

dude, that's 500,000 mg...you wanna kill him? :o

[mudlord]

Clearly, since the person said and I quote
"what a ass. It's almost like every single message he posts here has to fill an insult quota.".

So you know what, you can shove that chill pill up your Dolphin raping ass.