ARM-software/tracetooltests

Última actividad de origen registrada: 7 de junio de 2026 a las 17:31

Catálogo de SkillsMP actualizado: 5 de noviembre de 2026 a las 19:57

skills recopiladas: 8

Estrellas en GitHub: 9
Forks en GitHub: 13

Instalar con un asistente de IA

Copia este prompt en el asistente de IA que estés usando.

Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/ARM-software/tracetooltests.

README del repositorio

Archivo de origen del README: README.md

Leer el README original

Mostrar README completo

tracetooltests ============== This is a repository of tests designed for testing tracing tools. Building -------- To build for linux desktop: -------------------------- You may need to install the LunarG SDK first to get up to date headers. You also may need to install some dependencies. For Ubuntu: ``` sudo apt-get install xvfb libvulkan-dev cmake g++ xorg-dev libglu1-mesa-dev libwayland-dev python3 libxcb-randr0-dev ``` Then run: ``` mkdir build cd build cmake .. make make test ``` See below for selecting your window system backend. You can set the `NO_GLES`, `NO_VULKAN` and `NO_CL` cmake variables to skip building parts of the codebase you are not interested in. Linux cross-compile ------------------- ``` mkdir build_name cd build_name ``` Then ONE of the following for ARMv7 or ARMv8, respectively: ``` cmake -DCMAKE_TOOLCHAIN_FILE=cmake/toolchains/fbdev_arm.cmake .. cmake -DCMAKE_TOOLCHAIN_FILE=cmake/toolchains/fbdev_aarch64.cmake .. ``` Then complete as normal with: ``` make ``` Android emulator cross-compile ------------------------------ ``` cmake --preset android-x86_64 cd build-android-x86_64 ninja ``` Android native cross-compile ---------------------------- ``` cmake --preset android-arm64 cd build-android-arm64 ninja ``` Building for another GLES backend --------------------------------- The default backend for GLES is `x11`. To change the backend, pass `-DWINDOWSYSTEM=<name of backend>` where the backend can be one of the following: * sdl * fbdev * pbuffers * x11 GLES tests built for X11 or pbuffers accept `-D/--device N` to select an enumerated EGL device by index. `-G/--gpu` and `-C/--cpu` select the first identifiable GPU or CPU device. Either can be combined with `--device N` to require that the indexed device has the requested type. Unknown device types are not selected by `--gpu` or `--cpu`. Classification uses `EGL_EXT_device_type` when available, with Mesa software-device and DRM render-node fallbacks. The test prints the available indices, device types, and active GL renderer. X11 selection requires `EGL_EXT_explicit_device`; pbuffer selection requires the `EGL_EXT_platform_device` client extension. If the X11 display binds a different device, the test skips rather than silently using it. On Mesa, `--cpu` enables `LIBGL_ALWAYS_SOFTWARE` and `--gpu` disables it before initializing EGL, so X11 selects the intended renderer. Selection is not supported by the SDL or fbdev builds; without these options, the usual display selection remains unchanged. The Vulkan tests are currently not using any window system. Modifying runs -------------- Most tests have command line parameters. To see which, run it with --help These environment variables can be set to modify the tests: * `TOOLSTEST_TIMES` - the number of frames or loops to run * `TOOLSTEST_SANITY` - whether or not to inject sanity checking assert calls * `TOOLSTEST_NULL_RUN` - if set, we will skip testing whether results make sense; useful for generating test runs on fake drivers * `TOOLSTEST_STEP` - enter step mode where we wait for keypress to proceed to the next frame; while 'q' will exit immediately (GLES only for now) * `TOOLSTEST_WINSYS` - change Vulkan winsys; only valid value for now is "headless", which will force the headless extension to be used (Vulkan only for now) * `TOOLSTEST_VALIDATION` - enable validation layer (Vulkan only) Note that for fake driver runs where `TOOLSTEST_NULL_RUN` is required and traces are generated, any traces containing compute jobs will _not_ contain the correct buffer contents. Not all tests support all environment variables. For the vulkan tests, usually better to look at their command line options. Private Vulkan extensions ------------------------- `VK_TRACETOOLTEST_checksum_validation` - defines a new command vkAssertBufferTRACETOOLTEST(VkDevice device, VkBuffer buffer) which injects and returns an Adler32 checksum of the given buffer into the command stream. This can be used to validate tools like tracers. vkAssertImageTRACETOOLTEST(VkDevice device, VkImage image) planned for later. `VK_TRACETOOLTEST_layer_object_property` - defines a new command void vkGetLayerObjectPropertyTRACETOOLTEST(VkInstance instance, VkObjectType objectType, uint64_t objectHandle, VkLayerObjectPropertyTRACETOOLTEST valueType) which can request layer internal information from the layer supporting this extension. `VK_TRACETOOLTEST_trace_helpers` - various helper commands for tracing tools. Defines ways to mark buffer device addresses and shader group handles in memory for identification by tools. Private GLES extensions ----------------------- TBD Known issues ------------ * The multi-surface tests do not work with the SDL backend. Ubuntu and OpenCL ----------------- * apt install ocl-icd-opencl-dev mesa-opencl-icd clinfo * For CPU emulation, also install pocl-opencl-icd * On Intel also install intel-opencl-icd AI code generation ------------------ Generating small code samples seems almost like a perfect match for AI code agents. We have an AGENTS.md file to help it along the way. Sadly, most AI sandboxes seem to block access to the GPU by default, but you can run some of the Vulkan samples with the --cpu option if you have llvmpipe installed.

Cargando el README del repositorio…