1 / 13

Status – Week 291

Status – Week 291. Victor Moya. Tracing 3D applications. Three layers or levels for tracing:. 3D Appl. API Trace. API. Driver Trace (IOCTL?). Driver. OS. GPU Commands Trace. GPU. Tracing 3D applications.

rgamble
Télécharger la présentation

Status – Week 291

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status – Week 291 Victor Moya

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

  3. Tracing 3D applications • 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). • We need all the parameters (vertexs, primitives, textures, bitmaps and other parameters). • Timing needed? API seems to need just sorted trace.

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

  5. API Traces • DirectX/Direct3D: • Propietary API. Graphic chip manufacturers implement a smaller (hidden?) API behind the open API. • 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 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.

  6. API Traces • Conclusions: • 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. • 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 through emulation with WineX implies modifying WineX code (not hard). Problem: how much of the D3D functionality is already implemented.

  7. Driver Traces • Two approach: • 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.

  8. Driver Traces • 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. • 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.

  9. Driver Traces • Windows: • 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.

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

  11. Hardware command trace • 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. • Windows: • 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.

  12. Conclusion • API traces seem the easiest option. • 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? • If real semantic is important perhaps could be posponed.

  13. Planificación ?

More Related