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
There needs to be some supported method to allow integration of instrumentation profilers in the rendering code when using SDL_GPU.
At the very least, this would require exposing handles/pointers/objects from the back-end APIs themselves which is currently treated as an internal detail (#10876).
However, just exposing the handles may not be enough, since it is possible that the source code location where the calls to the profiler library are supposed to be made might be within the SDL library itself. That is to say, it is possible that by the time the user gets control, it might be too late to make the appropriate call.
If that is the case, we would need to be able to set some callbacks that are called in some well defined places within the library. It might also be possible to expose this using the Event system if the callback-based SDL_AppEvent is being used; so that at some well defined points within SDL_GPU , the corresponding event is added to the event queue and SDL_AppEvent is called before moving forward with the respective operation.
And the nuclear option might be to simply add an API to expose the various counters, etc. through SDL_GPU system itself, thus allowing us to write our own profilers.
The text was updated successfully, but these errors were encountered:
There needs to be some supported method to allow integration of instrumentation profilers in the rendering code when using SDL_GPU.
At the very least, this would require exposing handles/pointers/objects from the back-end APIs themselves which is currently treated as an internal detail (#10876).
For example, integrating Tracy requires:
ID3D12Device*
,ID3D12CommandQueue*
,ID3D12GraphicsCommandList*
VkPhysicalDevice
,VkInstance
,VkPhysicalDevice
,VkDevice
,VkQueue
,VkCommandBuffer
MTLDevice
,MTLComputePassDescriptor*
,MTLBlitPassDescriptor*
,MTLRenderPassDescriptor*
,MTLComputeCommandEncoder
However, just exposing the handles may not be enough, since it is possible that the source code location where the calls to the profiler library are supposed to be made might be within the SDL library itself. That is to say, it is possible that by the time the user gets control, it might be too late to make the appropriate call.
If that is the case, we would need to be able to set some callbacks that are called in some well defined places within the library. It might also be possible to expose this using the
Event
system if the callback-basedSDL_AppEvent
is being used; so that at some well defined points within SDL_GPU , the corresponding event is added to the event queue andSDL_AppEvent
is called before moving forward with the respective operation.And the nuclear option might be to simply add an API to expose the various counters, etc. through SDL_GPU system itself, thus allowing us to write our own profilers.
The text was updated successfully, but these errors were encountered: