Graphics compatibility feedback?

[unknownbrackets]

I was thinking of adding a feature that ran some tests through GL or the backend (not sure the best way, maybe pspautotests style, maybe just GL style...) which could identify problems that certain cards have.

For example, we saw that using a fixed value that was 0xFFFFFF behaved differently than GL_ONE, but we only had reports from GitHub comments to go on for this.

If instead we even just had a button that allowed users to "report graphics compatibility", we could centralize these metrics and see what methods fail for which devices. Case in point, #1313. Does this actually fail on all PowerVR devices? Is it a bug and failing on Mali also, or is it only certain PowerVR devices? Do we want to send a slew of builds to just one user to find out, even if that one user ends up being on some ancient buggy driver version and it's only affecting them?

But, I'm not sure the best way to architect the graphics tests. If we do it through PSP code, we get cross-backend testing for free. However, we also lose the ability to test around our existing compatibility hacks, and we can't test methods we don't currently employ.

-[Unknown]

[Joelgp83]

Dumb question, but assuming for the moment that this would be a button under system tools (e.g. "Benchmark compatibility", or some other way of putting it), would it not be possible to run it as psp code, but have two sets of tests (and therefore two buttons), one that does explicitly sets things up so that you can test around the existing compatibility hacks, and one that won't?

Or heck, do it PC benchmark style, and just break it out as an included iso that the emulator calls thats all types of testing in psp code, whatever backends, every which way. Include a button to "download latest benchmark iso", so the entire test suite would be self-contained and can be updated independently of the main program?

edited for clarity of thought

[unknownbrackets]

But the issue still remains. If we have code in the backend that never uses 0xFFFFFF and always uses GL_ONE, it will not be possible to trigger any behavior other than GL_ONE no matter what the code on the ISO is.

-[Unknown]

[hrydgard]

Yeah, any tests like this will have to be done outside of the PSP emulation. We can simply add a Test/Benchmark tool under Tools to try things out, and maybe in the future even possibly run it on first run, detect misbehaviours and alter settings accordingly. However, it's really sad to have to resort to that...

[Joelgp83]

Ok, well, even if has to be outside the psu emulation, I still think that it'd be worth it for this to be either modularized or separated out in such a away that the test suite could be updated independently if new tests need to added outside of a normal update

[asbel123]

i got this websites talk about gpu flops and about mobile gpu how worse is snapdragon 810 overheat look at this websites.

i got the websistes link is kyokojap.myweb.hinet.net/gpu_gflops/ its a wiki talks about all mobile gpu this why u getting issues of power vr difference to mali check it out.

[hrydgard]

GFLOPS measures are almost entirely irrelevant for PPSSPP given how ridiculously slow the drivers are for many mobile chips, especially Qualcomm. I'm working on a new graphics backend that will "precook" the graphics commands more to create less work for the drivers, but it remains to be seen how much that can help.

But this issue is about accuracy problems, not speed, anyway.

[hrydgard]

Kind of related to this, I've added a utility to test for known GPU bugs in Tools/Developer Tools/GPU Driver Test.