GPU support on the headless version

[soywiz]

In order to test gpu renderings, headless version should support opengl rendering.

I done that before on my D emulator (if it helps):
http://code.google.com/p/pspemu/source/browse/trunk/src/pspemu/core/gpu/impl/gl/GpuOpenglUtils.d

The idea to be able to create an accelerated opengl context (on windows) on a console app is to create an invisible window and request a context for that window.

[hrydgard]

Yes, this should absolutely be done. Is there some nice crossplatform way to do it?

[soywiz]

I know there is glut. But don't know if it has api for offscreen rendering.
On C# I used OpenTK, that did already all the work. Maybe reading some parts of the source would help.
But I dont think there will be a crossplatform way. But offscreen rendering would be useful just on desktop platforms: mac, linux and windows.
To initializate a context on windows you use wgl api and on linux glx.
http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib
http://www.gamedev.net/topic/613994-question-about-opengl-initialization-for-offscreen-rendering/

[unknownbrackets]

I took a quick stab at this:

https://github.com/unknownbrackets/ppsspp/compare/headless

But I guess the harder part is comparing the results? I mean, I assume we want to have some acceptable level of variance or something, but maybe not...?

Edit: also, native spits all kinds of stuff out to stdout too, making the python script less than entirely happy.

-[Unknown]

[unknownbrackets]

So, what about using ImageMagick's compare? I know it's an external dependency, but it's often available and easy to install on Windows. We could then maybe define in the test (perhaps printf("Allowed variance: X\n"); or something) how correct it must be?

-[Unknown]

[hrydgard]

Sounds good to me, although we could also simply add some basic image comparer to PPSSPP itself, you could send in the picture to compare to as an argument. We can already load PNGs and comparing is just a matter of looping through the pixels and computing some sort of error sum and then thresholding it...

[unknownbrackets]

Well, comparing it directly is fine, I'm just worried about the error sum / threshold part.

unknownbrackets/ppsspp@hrydgard:master...screenshot

I took a stab at it, but I'm obviously doing it wrong. Copying the vram gets me black (which is what it does in the emulator), and glReadPixels() didn't work either (but I probably used it wrong, I just used GL_BACK.)

I have verified it's actually drawing... at least, I can see things if I set WINDOW_VISIBLE to true.

-[Unknown]

[unknownbrackets]

Have this working now, I just need to clean it up a bit and write a few clean tests to validate it's working properly.

-[Unknown]

[hrydgard]

Cool!

[hrydgard]

Btw, we should add an option in PPSSPP to write the image (and depth buffer etc) back to VRAM properly, it is possible that some game would use the CPU to read the frame or depth buffer, this is especially common with games that want to check if their sun lens flare should be drawn or not by checking the depth buffer at the position of the sun...

Of course this is very expensive so should only be used for games that would really need it.

[dbz400]

is it a new feature ? or already implemented but need to toggle for performance wise

[hrydgard]

What we're talking about here is to be able to write GPU test, where we run a little test program on both PSP and PPSSPP and compare the resulting images.

But yes that part (reading back the image from an OpenGL buffer to VRAM) can indeed become a feature with a toggle. I don't know if many games will need it.

[dbz400]

I see .thanks for explain it to me . i think you mean to put those depth/color test as an option to toggle .correct me if i'm wrong .

[Orphis]

If a game is going to check for the VRAM, they will have to wait that drawing is done and use SIGNAL with SYNC or something similar. We can probably use this at our advantage.