「利用者:Brita/GSoC BGE debug and profiling/Proposal」の版間の差分

提供: wiki
移動先: 案内検索
 
(1版 をインポートしました)
 
(相違点なし)

2018年6月29日 (金) 05:56時点における最新版

Original Proposal: Improved Debugging and Profiling in BGE

Synopsis

This project aims to bring common profiling options to BGE, extending and improving the existing ones, namely: resources spent with user logic, rendering different objects and how much of the graphics card memory and capabilities is being used. Another objective of this project is to improve debug using the new OpenGL debugging system.


Benefits to Blender

Users will have access to better debugging and performance data without the need of an external tool. This will allow Blender games to be written in less time due to better debugging, as errors and problems can be found, understood, and corrected faster. Not needing an external tool will also reduce the time needed to access the game's performance. It should be noted that many of BGE users may not even know how to profile a graphics application with an external tool.

Blender developers can also make use of the debugging system, notably when developing with OpenGL. It can be particularly useful in aiding developers migrating Blender to OpenGL 3.x and in detecting performance problems, previously silent errors and the use of features that might not be portable.

Lastly, this project can improve the final result's quality by producing a less resource-consuming game if the user has optimized it.


Deliverables

  • new debugging tools;
  • new profiling statistics for vram usage, miscellaneous OpenGL statistics, detailed render time, and time spent on the user's python scripts;
  • graph output for statistics;
  • UI for choosing what statistics to display.

Project Details

This project comprises the inclusion of the new OpenGL debug features that are also accessible via extension in reasonably old cards. The usage of debug callbacks can help users to better understand various types of problems, from errors to performance issues. This new system can also differentiate if the error is due to shader code, blender code, user code, etc.

The debug output can be enabled or disabled at any time and can be controlled through filters and/or groups. These filters and groups should be particularly useful to developers. The groups allow the definition of the verbosity for independently registered components so that the developer can focus on his specific task, and the filters allow to specify that, for example, only messages related to medium and high severity errors and performance should be presented.

The main component of this proposal is improved profiling. The existing statistics should be extended so as to provide more detailed or new useful data. Several OpenGL statistics can be added, such as: OpenGL calls per frame and Vertices, Triangles, Lines, Points, Primitives and Texels also per frame.

Planned improvements on already existing statistics are detailed rendering times and python scripting profiling, now shown as Rasterizer and Logic respectively. It would be ideal to have an estimated rendering time for every active object in the scene, and, for the logic, to provide information to the user on which of his scripts is taking longer. This would allow the user to determine where the bottleneck is.

The graphics card memory can also be profiled and displayed, including total vram usage, the size of each object's VBO and memory leak detection.

All this statistics can also be presented in graph form that could either be saved into a file or presented in real-time (with some thoughts as the to the UI).

This should be made as generic as possible to account for a possible integration in Cycles.

Finally, it could be interesting for the user to configure how to display the profiling data and what data to display. For this, this project aims to provide an UI that can enable and disable the viewing and calculation of the different statistics.


Project Schedule

I can begin working as soon as gsoc officially starts. As for other things, mostly I will only have my thesis to deliver, with due date on October. A rough timeline for the project follows, assuming 13 weeks:

  • (1-4) setup OpenGL debugging callbacks
  • (5) create the UI for selecting what statistics to display
  • (6) add support for profiling the user's python scripts individually
  • (7) OpenGL statistics (number of vertices, etc, per frame)
  • (7-9) add support for presenting detailed render time
  • (10-11) add support for checking of vram usage and memory leaks
  • (12) implement graph output
  • (13) tiding up and writing documentation
All steps include testing.