Status – Week 291 Victor Moya

Tracing 3D applications Three layers or levels for tracing: Three layers or levels for tracing: 3D Appl API Driver GPU API Trace Driver Trace (IOCTL?) GPU Commands Trace OS

Tracing 3D applications Each layer is more difficult to trace (kernel level code) and less documented (rather not documented at all). Each layer is more difficult to trace (kernel level code) and less documented (rather not documented at all). APIs are (and must) fully documented and easy to trace (user level). APIs are (and must) fully documented and easy to trace (user level). We need all the parameters (vertexs, primitives, textures, bitmaps and other parameters). We need all the parameters (vertexs, primitives, textures, bitmaps and other parameters). Timing needed? API seems to need just sorted trace. Timing needed? API seems to need just sorted trace.

API Traces OpenGL: OpenGL: Open standard (yet :P). Open standard (yet :P). Open source implementations (Mesa). Open source implementations (Mesa). GLSim( a-01-fall/glsim.html): provides the source of an instrumented OpenGL library (linux and win32), tools and trace examples (quake, unreal). GLSim( a-01-fall/glsim.html): provides the source of an instrumented OpenGL library (linux and win32), tools and trace examples (quake, unreal). a-01-fall/glsim.htmlhttp://graphics.stanford.edu/courses/cs448 a-01-fall/glsim.html Trace sizes: binary gziped format (tlg.gz, glt.gz from GLSim), Unreal 185 frames 57 MB, Quake3demo MB, qtpvr 734 frames 27 mb. Trace sizes: binary gziped format (tlg.gz, glt.gz from GLSim), Unreal 185 frames 57 MB, Quake3demo MB, qtpvr 734 frames 27 mb.

API Traces DirectX/Direct3D: DirectX/Direct3D: Propietary API. Graphic chip manufacturers implement a smaller (hidden?) API behind the open API. Propietary API. Graphic chip manufacturers implement a smaller (hidden?) API behind the open API. Debug DLLs: amount of information they provide unknown (symbols, OutPutDebugString). Debug DLLs: amount of information they provide unknown (symbols, OutPutDebugString). Use an instrumented DLL (GLTrace). Has to be implemented, multiple DLLs in D3D, functions that must be implemented. Use an instrumented DLL (GLTrace). Has to be implemented, multiple DLLs in D3D, functions that must be implemented. Use a debugger (win32 debug API) to trace all the DirectX/Direct3D function calls. Use a debugger (win32 debug API) to trace all the DirectX/Direct3D function calls. Use WineX (open source DirectX emulator for Linux) to get traces of DX/D3D calls. Use WineX (open source DirectX emulator for Linux) to get traces of DX/D3D calls.

API Traces Conclusions: Conclusions: OpenGL would be rather easy to obtain in Linux: GLSim, Mesa, DRI. OpenGL would be rather easy to obtain in Linux: GLSim, Mesa, DRI. OpenGL in Windows can be easily achieved as it is only a task of replacing opengl32.dll (and maybe linking with your own opengl.lib). GLSim compiles for win32. OpenGL in Windows can be easily achieved as it is only a task of replacing opengl32.dll (and maybe linking with your own opengl.lib). GLSim compiles for win32. Use GLTrace util (Linux and Windows). Not tested yet. With source code. Use GLTrace util (Linux and Windows). Not tested yet. With source code. DX/D3D traces in Windows could be done also with instrumented DLLs. Some problems: protected dll names (try with DOS), multiple files, functions. If not a debugger/tracer could work. DX/D3D traces in Windows could be done also with instrumented DLLs. Some problems: protected dll names (try with DOS), multiple files, functions. If not a debugger/tracer could work. DX/D3D traces through emulation with WineX implies modifying WineX code (not hard). Problem: how much of the D3D functionality is already implemented. DX/D3D traces through emulation with WineX implies modifying WineX code (not hard). Problem: how much of the D3D functionality is already implemented.

Driver Traces Two approach: Two approach: Hack the kernel: instrument (through kernel debugger or modified drivers) Hack the kernel: instrument (through kernel debugger or modified drivers) Hack the access to the driver: instrument the API library and intercept all the IOCTL calls (or whatever call is used to access the driver). Only a normal debugger/tracer (custom though) is needed. Hack the access to the driver: instrument the API library and intercept all the IOCTL calls (or whatever call is used to access the driver). Only a normal debugger/tracer (custom though) is needed.

Driver Traces Linux: Linux: DRI provides the source code for API and kernel level drivers for some graphic chips (ATI up to R200 and 3dfx). Would be easy to get driver traces or even raw hardware commands for those chips. DRI provides the source code for API and kernel level drivers for some graphic chips (ATI up to R200 and 3dfx). Would be easy to get driver traces or even raw hardware commands for those chips. Modify kernel to support debugging/tracing for specific drivers. If it can be done would work for most Nvidia chips. Just intercept IOCTL calls. I don’t know how it really work the Linux kernel and its drivers. Modify kernel to support debugging/tracing for specific drivers. If it can be done would work for most Nvidia chips. Just intercept IOCTL calls. I don’t know how it really work the Linux kernel and its drivers.

Driver Traces Windows: Windows: Hack IOCTL in the API (in hardware specific part, not MS) seems the easier. But requires to discover where are those calls. Hack IOCTL in the API (in hardware specific part, not MS) seems the easier. But requires to discover where are those calls. Kernel level debugging? Maybe through vxds (virtual devices, give access to kernel level). Seems hard and would need more research. Kernel level debugging? Maybe through vxds (virtual devices, give access to kernel level). Seems hard and would need more research.

Hardware command trace Very difficult to get: Very difficult to get: No source code. No source code. Unknown command specifications. Unknown command specifications. Kernel level. Kernel level.

Hardware command trace Linux: Linux: Try to modify kernel for intercept ‘access to hardware’ from the drivers. Requires to know how the hardware is accessed (IO, mem. mapped IO, DMA …). I’m not sure if it is really possible. Try to modify kernel for intercept ‘access to hardware’ from the drivers. Requires to know how the hardware is accessed (IO, mem. mapped IO, DMA …). I’m not sure if it is really possible. Windows: Windows: Same, but without access to kernel code. Through somekind of vxd. Same, but without access to kernel code. Through somekind of vxd. Emulation: full PC emulation would provide with a slow way to get anything we want. Emulation: full PC emulation would provide with a slow way to get anything we want.

Conclusion API traces seem the easiest option. API traces seem the easiest option. API traces used by Standford and others (and they should know what they are doing). API traces used by Standford and others (and they should know what they are doing). API and drivers hide the real semantic of the hardware, but it is really so different? API and drivers hide the real semantic of the hardware, but it is really so different? If real semantic is important perhaps could be posponed. If real semantic is important perhaps could be posponed.

Planificación ?