(08-26-2019, 08:09 PM)JosJuice Wrote: [ -> ]Not really... Once that video gets into gameplay, the speed doesn't go over 85% and often stays around 75%. And judging by how the goop collision doesn't work correctly, they most be using the inaccurate settings that speed up Super Mario Sunshine significantly (or maybe the drivers just don't support EFB copies correctly?)
EDIT: Ah yes, upon a closer look they deleted the whole Sys/GameSettings/ folder. That would cause the Super Mario Sunshine inaccuracies. (Please never delete that whole folder.)
But Sunshine's .ini file doesn't really have anything except a list of AR and Gecko codes. What would it's presence really do to Sunshin's accuracy. I would say it has more to do with them turning on all the speedhacks within Dolphin.
(08-28-2019, 05:53 AM)myownfriend Wrote: [ -> ]But Sunshine's .ini file doesn't really have anything except a list of AR and Gecko codes. What would it's presence really do to Sunshin's accuracy. I would say it has more to do with them turning on all the speedhacks within Dolphin.
You might have been looking at the wrong INI. It's understandable, we structure INI's to have a "global" INI, and then region specific INIs. For AR/Gecko mostly.
https://github.com/dolphin-emu/dolphin/blob/9cfcbfacbe66a7d9615923ca45761b120c971759/Data/Sys/GameSettings/GMS.ini
Sunshine turns off EFB to texture and enables perf queries. Both of these are non-trivial performance hits.
myownfriend Wrote:I would say it has more to do with them turning on all the speedhacks within Dolphin.
Dolphin is designed to go as fast as possible (all speedhacks and tricks) by default, then uses the INI files to selectively disable speedhacks that don't cooperate with a particular game. Whenever we disable a speedhack we carefully weigh the balance between performance vs accuracy, so if a game gets a big speedup from deleting the INI, you're probably going to run into a game breaking bug that was severe enough to warrant that performance decrease.
Just like with Mario Sunshine, where you literally can't beat the game with all speedhacks enabled! So that video broke Sunshine for that performance.
This is about what I expected from the performance, if they can get that driver update, it should run some games well enough to be comparable to how the RPi3 ran N64 games.
(08-29-2019, 06:43 AM)jdonald Wrote: [ -> ]ETA PRIME walked through zRevengee's tutorial and tested 10 more games: https://www.youtube.com/watch?v=l4TyYU9Xhcs
Any thoughts on the backtrace I posted or how I can validate EXT_buffer_storage by itself?
Barring some kind of breakthrough it'll probably be best just to wait for the Pi to become Mesa OpenGL ES 3.1 compliant which seems to be a matter of when it happens not if it happens based on Pi engineer comments.
Okay I compiled and ran with -fsanitize=address. It's just a faster way to get basically the same stack trace. From here it's clear that the allocation in StreamBuffer.cpp is failing, i.e. GL_EXT_buffer_storage isn't working in Mesa 19.3.
(08-29-2019, 08:05 AM)bomblord Wrote: [ -> ]it'll probably be best just to wait for the Pi to become Mesa OpenGL 3.1 compliant
You mean OpenGL ES 3.1.
But if it were that simple, this would be working already. As 6by9 said on the Pi forums the current 3.1 compliance issues are unrelated to EXT_buffer_storage, so in theory just manually forcing it on would have been sufficient. Yet these backtraces have shown that exposing EXT_buffer_storage does not result in a working implementation.
Keep in mind that 3.1 is only the
minimum profile version to permit exposing GL_EXT_buffer_storage. From what I can tell, as an
extension by definition it's optional for any level of GLES compliance. The Igalia team can complete their roadmap and release a Mesa V3D driver with OpenGL ES 3.2 support and buffer storage could still be unsupported.
Next, I managed to compile and run VK-GL-CTS for the intent of testing the equivalent GL_ARB_buffer_storage. I could find only one test that covers it as indicated by
these lines. Apparently it only runs this case if
GL_ARB_sparse_buffer is also available (which is not the case for V3D) so the functionality may not actually be tested or implemented.
Thanks! I'll point the graphics devs at this.
No promise that we'll fix anything but they might be interested in looking. FIFO logs help.
(09-01-2019, 12:08 PM)Helios Wrote: [ -> ]Thanks! I'll point the graphics devs at this.
No promise that we'll fix anything but they might be interested in looking. FIFO logs help.
Every avenue seems worth exploring at this point thanks for the plug.