You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FNA now supports many renderers, more than 3 times what FNA supported just two years ago. Additionally, the renderers we support are far more complex and require a lot of testing to ensure high accuracy, stability, and performance. With this in mind, we need to start working on adding functionality that dramatically simplifies mass testing of new features and renderers.
The first step is to add a tracing tool to FNA3D. In short: We need a system that, when enabled, captures all incoming FNA3D calls (and their associated data) and writes it to a file that can be played back with a simple program. The API used when capturing should not matter, and when playing the file back you should be able to use any backend that FNA3D currently supports. The one exception to this rule would be any trace that uses the SysRenderer APIs, as that requires data outside FNA3D's own scope.
Once this is done, we can simply do captures of our whole catalog, and as long as the ABI doesn't break we can very easily test new renderers locally while also integrating the catalog into a GitHub Action that plays everything back against a bunch of reference devices (WARP, llvmpipe GL/VK, etc.) to trivially catch regressions regarding accuracy and stability. Performance is a bit tougher to test, but that can be checked out after we have a good testing system in place for the basic stuff.
The text was updated successfully, but these errors were encountered:
As of the latest commit, tracing should now be fully-functional for single-threaded applications. Just need to add a mutex to the tracer and this is good to review...
FNA now supports many renderers, more than 3 times what FNA supported just two years ago. Additionally, the renderers we support are far more complex and require a lot of testing to ensure high accuracy, stability, and performance. With this in mind, we need to start working on adding functionality that dramatically simplifies mass testing of new features and renderers.
The first step is to add a tracing tool to FNA3D. In short: We need a system that, when enabled, captures all incoming FNA3D calls (and their associated data) and writes it to a file that can be played back with a simple program. The API used when capturing should not matter, and when playing the file back you should be able to use any backend that FNA3D currently supports. The one exception to this rule would be any trace that uses the SysRenderer APIs, as that requires data outside FNA3D's own scope.
Once this is done, we can simply do captures of our whole catalog, and as long as the ABI doesn't break we can very easily test new renderers locally while also integrating the catalog into a GitHub Action that plays everything back against a bunch of reference devices (WARP, llvmpipe GL/VK, etc.) to trivially catch regressions regarding accuracy and stability. Performance is a bit tougher to test, but that can be checked out after we have a good testing system in place for the basic stuff.
The text was updated successfully, but these errors were encountered: