(04-18-2011, 10:58 AM)gid15 Wrote: I must also admit that the Video configuration options are not always self-explanatory. This is because they are related on how to map the low-level PSP graphic functions to the OpenGL functions.
OpenGL provides some optimization techniques for application developers when they follow some basic principles (e.g. grouping the display of similar graphics together, reusing the same data at each frame...). The PSP does not use the same optimization techniques, e.g. there is no real advantage in grouping similar graphics together, or reusing the same data at each frame. So, the PSP programmers are optimizing for the PSP, which is not the same as optimizing for OpenGL.
The Video configuration options allow the activation/deactivation of OpenGL techniques: they might improve some games if their programmers by chance more or less followed the OpenGL principles, but they also might decrease the performance if the game programmers did something completely different (which is also legitimate on a PSP).

So, to the different options:
- Disable VBO: using OpenGL VBO (http://www.opengl.org/wiki/Vertex_Buffer_Object) should always bring a win. This option is probably useless.
- Only GE graphics: the PSP allows drawing using GE commands or by writing directly to the PSP framebuffer memory. With OpenGL, supporting both methods is cost expensive. When this option is activated, only the drawing using GE commands is supported. If the application writes directly to the PSP framebuffer memory, this is ignored. As a side effect, a more accurate FPS is displayed when enabling this option. When disabled, the displayed FPS is over-optimistic. This is why a lower FPS but a smoother/faster play is often reported. Trust the faster play, not the FPS
- Use Vertex Cache: when enabled, parts of the graphics (positions, colors, bones...) are loaded on the graphic card and reused from frame to frame when their data is not changing. This has however a negative impact if the game programmers are changing their data (e.g. the positions) very often. By the way, a texture cache is always used and cannot be disabled.
- Use shaders: use vertex and fragment shaders to implement most of the PSP functions. Some of the PSP functions cannot be implemented without the use of shaders, so this option should provide the most accurate rendering. Unfortunately, some shader implementations are somewhat buggy, depending on the graphic card used (e.g. AMD/ATI or Intel).
- Use a Geometry shader for 2D rendering: when using shaders, this option might bring a slight performance improvement for 2D applications.
- Disable UBO: when using shaders, OpenGL UBO's (http://www.opengl.org/wiki/Uniform_Buffer_Object) should bring a better performance. But again, some graphic card drivers have sometimes buggy implementations. This is why this option is enabled by default, and only a "Disable" option is available.
- Enable VAO: an OpenGL optimization (http://www.opengl.org/wiki/Vertex_Array_Object) when similar graphics are grouped together. This is just available as an option as most PSP programmers do not following this approach.
- Enable saving GE screen to Textures: the content of the PSP framebuffer is kept in an OpenGL texture instead of the PSP memory: This allows faster load/save from OpenGL, but breaks compatibility if the application is manipulating directly the framebuffer memory.
- Enable decoding of indexed textures (using CLUT) in shader: this option brings a performance boost when combined with "Enable saving GE screen to Textures" and when the application is doing manipulations on the Red/Green/Blue color channels of the framebuffer (e.g. to implement some graphic effects, blurs or shadows). Available only as an option as it might break the compatibility for other applications...
- Enable dynamic shader generation: we have a single shader implementing all the PSP functions. This shader contains of lot of condition tests ("if (mode==0) then xxx", "if (mode==1) then yyy") to support all the combinations. This option enables the generation of a separate shader for each combination. E.g., when mode==0, we create one shader containing only "xxx" and when mode==1, we create another shader containing only "yyy". Each of these shaders will then execute faster because it can avoid the condition test. Due to the large number of possible combinations, this could result in the generation of several hundred different shaders. As this might overload the graphic card driver, this feature is only available as an option. As a side effect, some graphic card drivers (e.g. AMD/ATI) are reported to be less buggy when using this option.

OK, enough for now, a very long response to a short question . And this should really belong to the Jpcsp documentation.