Skip to content
Commits on Source (559)
459 additional commits have been omitted to prevent performance issues.
Expand all Show whitespace changes
Inline Side-by-side
.travis.yml
View file @ 491d3735
......@@ -43,7 +43,7 @@ matrix:
env: ANDROID_BUILD=1
compiler: clang
- os: osx
osx_image: xcode9.1
osx_image: xcode9.4
env: APPLE_BUILD=1
compiler: clang
......
CMakeLists.txt
View file @ 491d3735
......@@ -3,27 +3,28 @@ cmake_minimum_required(VERSION 2.8.12)
# Configure some stuff that needs to be set really early
if(BUILD_ANDROID)
set(CMAKE_TOOLCHAIN_FILE
"${CMAKE_SOURCE_DIR}/util/android.toolchain.cmake"
"$ENV{ANDROID_NDK}/build/cmake/android.toolchain.cmake"
CACHE STRING
"The Android toolchain file")
option(STRIP_ANDROID_LIBRARY "Strip the resulting android library" OFF)
# Set same default API level for ANDROID_ABI=armeabi-v7a as for arm64-v8a.
set( ANDROID_DEFAULT_NDK_API_LEVEL_arm 21 )
# Set default API level to 21 if not configured explicitly
if(NOT ANDROID_PLATFORM)
set(ANDROID_PLATFORM "android-21")
endif()
# default to libc++_static as the other options can cause crashes
if(NOT ANDROID_STL)
set(ANDROID_STL "c++_static")
endif()
# Choose clang if the NDK has both gcc and clang, since gcc sometimes fails
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION "clang")
# Default to arm32 if nothing is specified on the command line.
# Options are {armeabi-v7a,arm64-v8a}
set(ANDROID_ABI "armeabi-v7a" CACHE STRING "The Android ABI to build for")
# This will be overridden later, we just need to set it now so that the
# configuration will continue on to where the toolchain is available
if(WIN32)
set(CMAKE_MAKE_PROGRAM
"android-make-not-found"
CACHE STRING
"The path to the NDK's make.exe to use")
endif()
endif()
# disallow in-source builds because we have a top-level wrapper Makefile
......@@ -141,8 +142,7 @@ set(RENDERDOC_VERSION "${RENDERDOC_VERSION_MAJOR}.${RENDERDOC_VERSION_MINOR}")
message(STATUS "Building RenderDoc version ${RENDERDOC_VERSION}")
if(APPLE)
message(STATUS "Disabling Vulkan and GLES drivers on apple")
set(ENABLE_VULKAN OFF CACHE BOOL "" FORCE)
message(STATUS "Disabling GLES driver on apple")
set(ENABLE_GLES OFF CACHE BOOL "" FORCE)
endif()
......@@ -163,21 +163,6 @@ if(ANDROID)
message(STATUS "Using Android ABI ${ANDROID_ABI}")
message(STATUS "Using Android native API level ${ANDROID_NATIVE_API_LEVEL}")
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(MAKE_SEARCH_DIRS "windows-x86_64" "windows")
# For windows, we need to use the make program in the NDK
foreach(dir ${MAKE_SEARCH_DIRS})
set(__makepath "${ANDROID_NDK}/prebuilt/${dir}/bin/make.exe")
if( EXISTS "${__makepath}" )
set(CMAKE_MAKE_PROGRAM "${__makepath}" CACHE STRING "" FORCE)
break()
endif()
endforeach()
message(STATUS "Using build tool ${CMAKE_MAKE_PROGRAM}")
endif()
endif()
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin")
......
CONTRIBUTING.md deleted 100644 → 0
View file @ cb50d2d6
This diff is collapsed.
README.md
View file @ 491d3735
......@@ -5,17 +5,17 @@
[![AppVeyor](https://ci.appveyor.com/api/projects/status/x46lrnvdy29ysgqp?svg=true)](https://ci.appveyor.com/project/baldurk/renderdoc)
[![Coverity Scan](https://scan.coverity.com/projects/8525/badge.svg)](https://scan.coverity.com/projects/baldurk-renderdoc)
RenderDoc is a frame-capture based graphics debugger, currently available for Vulkan, D3D11, D3D12, OpenGL, and OpenGL ES development on Windows 7 - 10, Linux, and Android. It is completely open-source under the MIT license.
RenderDoc is a frame-capture based graphics debugger, currently available for Vulkan, D3D11, D3D12, OpenGL, and OpenGL ES development on Windows 7 - 10, Linux, Android, and Nintendo Switch™. It is completely open-source under the MIT license.
If you have any questions, suggestions or problems or you can [create an issue](https://github.com/baldurk/renderdoc/issues/new) here on github, [email me directly](mailto:baldurk@baldurk.org) or [come into IRC](https://kiwiirc.com/client/irc.freenode.net/#renderdoc) to discuss it.
To install on windows run the appropriate installer for your OS ([64-bit](https://renderdoc.org/stable/1.0/RenderDoc_1.0_64.msi) | [32-bit](https://renderdoc.org/stable/1.0/RenderDoc_1.0_32.msi)) or download the portable zip from the [builds page](https://renderdoc.org/builds). On linux there is a [binary tarball](https://renderdoc.org/stable/1.0/renderdoc_1.0.tar.gz) available, or your distribution may package it. If not you can [build from source](CONTRIBUTING.md#compiling).
To install on windows run the appropriate installer for your OS ([64-bit](https://renderdoc.org/stable/latest/RenderDoc_latest_64.msi) | [32-bit](https://renderdoc.org/stable/latest/RenderDoc_latest_32.msi)) or download the portable zip from the [builds page](https://renderdoc.org/builds). On linux there is a [binary tarball](https://renderdoc.org/stable/latest/renderdoc_latest.tar.gz) available, or your distribution may package it. If not you can [build from source](docs/CONTRIBUTING/Compiling.md).
* **Downloads**: https://renderdoc.org/builds ( [Symbol server](https://renderdoc.org/symbols) )
* **Documentation**: [HTML online](https://renderdoc.org/docs), [CHM in builds](https://renderdoc.org/docs/renderdoc.chm), [Videos](http://www.youtube.com/user/baldurkarlsson/)
* **Contact**: [baldurk@baldurk.org](mailto:baldurk@baldurk.org), [#renderdoc on freenode IRC](https://kiwiirc.com/client/irc.freenode.net/#renderdoc)
* **Code of Conduct**: [Contributor Covenant](CODE_OF_CONDUCT.md)
* **Information for contributors**: [CONTRIBUTING.md](CONTRIBUTING.md), [Compilation instructions](CONTRIBUTING.md#compiling), [Roadmap](https://github.com/baldurk/renderdoc/wiki/Roadmap)
* **Code of Conduct**: [Contributor Covenant](docs/CODE_OF_CONDUCT.md)
* **Information for contributors**: [All contribution information](docs/CONTRIBUTING.md), [Compilation instructions](docs/CONTRIBUTING/Compiling.md), [Roadmap](https://github.com/baldurk/renderdoc/wiki/Roadmap)
Screenshots
--------------
......@@ -37,6 +37,8 @@ API Support
| D3D9 & 10 | :heavy_multiplication_x: | N/A | N/A |
| Metal | N/A | N/A | N/A |
* Nintendo Switch™ support is distributed separately for authorized developers as part of the NintendoSDK. For more information, consult the Nintendo Developer Portal.
Downloads
--------------
......@@ -58,10 +60,13 @@ License
RenderDoc is released under the MIT license, see [LICENSE.md](LICENSE.md) for full text as well as 3rd party library acknowledgements.
Compiling
---------
Building RenderDoc is fairly straight forward on most platforms. See [Compiling.md](docs/CONTRIBUTING/Compiling.md) for more details.
Contributing & Development
--------------
Building RenderDoc is fairly straight forward. See [CONTRIBUTING.md](CONTRIBUTING.md#compiling) for more details.
I've added some notes on how to contribute, as well as where to get started looking through the code in [CONTRIBUTING.md](CONTRIBUTING.md).
I've added some notes on how to contribute, as well as where to get started looking through the code in [Developing-Change.md](docs/CONTRIBUTING/Developing-Change.md). All contribution information is available under [CONTRIBUTING.md](docs/CONTRIBUTING.md).
debian/changelog
View file @ 491d3735
renderdoc (1.2+dfsg-1) unstable; urgency=medium
* d/patches: Rebase for 1.2
* d/watch: renderdoc-modified-6 (swig fork) was released
* d/control: Standards-Version: 4.2.0 => 4.2.1
-- Jordan Justen <jordan.l.justen@intel.com> Wed, 05 Dec 2018 01:34:12 -0800
renderdoc (1.1+dfsg-1) unstable; urgency=medium
* d/patches: Update patches for renderdoc 1.1
......
debian/control
View file @ 491d3735
......@@ -22,7 +22,7 @@ Build-Depends: bison,
python3-dev,
qt5-qmake,
qtbase5-dev
Standards-Version: 4.2.0
Standards-Version: 4.2.1
Homepage: https://renderdoc.org/
Vcs-Git: https://salsa.debian.org/xorg-team/app/renderdoc.git
Vcs-Browser: https://salsa.debian.org/xorg-team/app/renderdoc
......
debian/patches/0001-use-debian-glslang-for-renderdoc-spirv-driver.patch
View file @ 491d3735
......@@ -5,9 +5,9 @@ Subject: use debian glslang for renderdoc spirv driver
---
renderdoc/CMakeLists.txt | 6 ++
renderdoc/driver/gl/gl_shader_refl.cpp | 2 +-
renderdoc/driver/shaders/spirv/CMakeLists.txt | 93 ++--------------------
renderdoc/driver/shaders/spirv/CMakeLists.txt | 94 ++--------------------
renderdoc/driver/shaders/spirv/spirv_common.cpp | 2 +-
renderdoc/driver/shaders/spirv/spirv_common.h | 4 +-
renderdoc/driver/shaders/spirv/spirv_common.h | 6 +-
renderdoc/driver/shaders/spirv/spirv_compile.cpp | 4 +-
.../driver/shaders/spirv/spirv_disassemble.cpp | 12 +--
renderdoc/driver/shaders/spirv/spirv_editor.h | 2 +-
......@@ -16,13 +16,13 @@ Subject: use debian glslang for renderdoc spirv driver
renderdoc/driver/vulkan/vk_info.cpp | 2 +-
renderdoc/driver/vulkan/vk_overlay.cpp | 2 +-
renderdoc/driver/vulkan/vk_postvs.cpp | 4 +-
13 files changed, 30 insertions(+), 107 deletions(-)
13 files changed, 31 insertions(+), 109 deletions(-)
diff --git a/renderdoc/CMakeLists.txt b/renderdoc/CMakeLists.txt
index b236740..0e1a063 100644
index c4195a4..8295c83 100644
--- a/renderdoc/CMakeLists.txt
+++ b/renderdoc/CMakeLists.txt
@@ -364,6 +364,12 @@ endif()
@@ -395,6 +395,12 @@ endif()
if(ENABLE_GL OR ENABLE_GLES OR ENABLE_VULKAN)
add_subdirectory(driver/shaders/spirv)
list(APPEND renderdoc_objects $<TARGET_OBJECTS:rdoc_spirv>)
......@@ -36,7 +36,7 @@ index b236740..0e1a063 100644
option(USE_INTERCEPTOR_LIB OFF)
diff --git a/renderdoc/driver/gl/gl_shader_refl.cpp b/renderdoc/driver/gl/gl_shader_refl.cpp
index 35a87d2..d55382d 100644
index e41f066..2dc0970 100644
--- a/renderdoc/driver/gl/gl_shader_refl.cpp
+++ b/renderdoc/driver/gl/gl_shader_refl.cpp
@@ -25,7 +25,7 @@
......@@ -49,10 +49,10 @@ index 35a87d2..d55382d 100644
void sort(rdcarray<ShaderConstant> &vars)
diff --git a/renderdoc/driver/shaders/spirv/CMakeLists.txt b/renderdoc/driver/shaders/spirv/CMakeLists.txt
index 8ee73e4..004b9e1 100644
index e01e52e..0ffc060 100644
--- a/renderdoc/driver/shaders/spirv/CMakeLists.txt
+++ b/renderdoc/driver/shaders/spirv/CMakeLists.txt
@@ -1,88 +1,3 @@
@@ -1,89 +1,3 @@
-set(glslang_dir ${RDOC_SOURCE_DIR}/3rdparty/glslang)
-set(glslang_sources
- ${glslang_dir}/OGLCompilersDLL/InitializeDll.cpp
......@@ -70,6 +70,7 @@ index 8ee73e4..004b9e1 100644
- ${glslang_dir}/SPIRV/Logger.h
- ${glslang_dir}/SPIRV/SpvBuilder.cpp
- ${glslang_dir}/SPIRV/SpvBuilder.h
- ${glslang_dir}/SPIRV/SpvPostProcess.cpp
- ${glslang_dir}/SPIRV/spvIR.h
- ${glslang_dir}/glslang/GenericCodeGen/CodeGen.cpp
- ${glslang_dir}/glslang/GenericCodeGen/Link.cpp
......@@ -141,7 +142,7 @@ index 8ee73e4..004b9e1 100644
set(sources
spirv_common.cpp
spirv_common.h
@@ -90,8 +5,7 @@ set(sources
@@ -91,8 +5,7 @@ set(sources
spirv_editor.cpp
spirv_compile.cpp
spirv_disassemble.cpp
......@@ -151,7 +152,7 @@ index 8ee73e4..004b9e1 100644
add_definitions(-DAMD_EXTENSIONS)
add_definitions(-DNV_EXTENSIONS)
@@ -101,9 +15,12 @@ set_source_files_properties(${glslang_sources}
@@ -102,9 +15,12 @@ set_source_files_properties(${glslang_sources}
if(CMAKE_COMPILER_IS_GNUCXX AND CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 7.0)
set_source_files_properties(${glslang_dir}/glslang/MachineIndependent/reflection.cpp
......@@ -179,19 +180,21 @@ index 8917b7e..889b7c5 100644
static bool inited = false;
std::vector<glslang::TShader *> allocatedShaders;
diff --git a/renderdoc/driver/shaders/spirv/spirv_common.h b/renderdoc/driver/shaders/spirv/spirv_common.h
index f6479b4..2d0be23 100644
index 0785ba1..19d020d 100644
--- a/renderdoc/driver/shaders/spirv/spirv_common.h
+++ b/renderdoc/driver/shaders/spirv/spirv_common.h
@@ -28,7 +28,7 @@
@@ -28,8 +28,8 @@
#include <string>
#include <utility>
#include <vector>
-#include "3rdparty/glslang/SPIRV/spirv.hpp"
-#include "3rdparty/glslang/glslang/Include/ResourceLimits.h"
+#include "SPIRV/spirv.hpp"
+#include "glslang/Include/ResourceLimits.h"
#include "api/replay/renderdoc_replay.h"
using std::string;
@@ -215,4 +215,4 @@ void glslangGetProgramResourceiv(glslang::TProgram *program, ReflectionInterface
@@ -225,4 +225,4 @@ void glslangGetProgramResourceiv(glslang::TProgram *program, ReflectionInterface
int32_t bufSize, int32_t *length, int32_t *params);
const char *glslangGetProgramResourceName(glslang::TProgram *program,
......@@ -214,10 +217,10 @@ index f0ca673..c6b7136 100644
TBuiltInResource DefaultResources = {
/*.maxLights =*/32,
diff --git a/renderdoc/driver/shaders/spirv/spirv_disassemble.cpp b/renderdoc/driver/shaders/spirv/spirv_disassemble.cpp
index 5ebc48c..97f7bec 100644
index 5488255..8b1413e 100644
--- a/renderdoc/driver/shaders/spirv/spirv_disassemble.cpp
+++ b/renderdoc/driver/shaders/spirv/spirv_disassemble.cpp
@@ -36,16 +36,16 @@ using std::make_pair;
@@ -37,16 +37,16 @@ using std::make_pair;
#undef min
#undef max
......@@ -267,7 +270,7 @@ index ec5b1c6..1f7973a 100644
#include "common/common.h"
diff --git a/renderdoc/driver/vulkan/vk_debug.cpp b/renderdoc/driver/vulkan/vk_debug.cpp
index 9ea26ba..8f957c2 100644
index e45859e..c40891d 100644
--- a/renderdoc/driver/vulkan/vk_debug.cpp
+++ b/renderdoc/driver/vulkan/vk_debug.cpp
@@ -24,7 +24,7 @@
......@@ -280,7 +283,7 @@ index 9ea26ba..8f957c2 100644
#include "driver/ihv/amd/amd_counters.h"
#include "driver/ihv/amd/official/GPUPerfAPI/Include/GPUPerfAPI-VK.h"
diff --git a/renderdoc/driver/vulkan/vk_info.cpp b/renderdoc/driver/vulkan/vk_info.cpp
index 71be261..be67ff2 100644
index c2a7497..ad165ab 100644
--- a/renderdoc/driver/vulkan/vk_info.cpp
+++ b/renderdoc/driver/vulkan/vk_info.cpp
@@ -23,7 +23,7 @@
......@@ -293,7 +296,7 @@ index 71be261..be67ff2 100644
void DescSetLayout::Init(VulkanResourceManager *resourceMan, VulkanCreationInfo &info,
const VkDescriptorSetLayoutCreateInfo *pCreateInfo)
diff --git a/renderdoc/driver/vulkan/vk_overlay.cpp b/renderdoc/driver/vulkan/vk_overlay.cpp
index 9b355d0..00523f1 100644
index 44820fd..10e29a1 100644
--- a/renderdoc/driver/vulkan/vk_overlay.cpp
+++ b/renderdoc/driver/vulkan/vk_overlay.cpp
@@ -23,7 +23,7 @@
......@@ -306,7 +309,7 @@ index 9b355d0..00523f1 100644
#include "driver/shaders/spirv/spirv_common.h"
#include "maths/camera.h"
diff --git a/renderdoc/driver/vulkan/vk_postvs.cpp b/renderdoc/driver/vulkan/vk_postvs.cpp
index 467b98f..45ff12c 100644
index 64e7415..9c2fa68 100644
--- a/renderdoc/driver/vulkan/vk_postvs.cpp
+++ b/renderdoc/driver/vulkan/vk_postvs.cpp
@@ -23,8 +23,8 @@
......
debian/patches/0002-qrenderdoc-MainWindow-Only-include-resource.h-on-win.patch
View file @ 491d3735
......@@ -8,7 +8,7 @@ Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
1 file changed, 2 insertions(+)
diff --git a/qrenderdoc/Windows/MainWindow.cpp b/qrenderdoc/Windows/MainWindow.cpp
index 486f864..e59737d 100644
index b302bab..06b6c40 100644
--- a/qrenderdoc/Windows/MainWindow.cpp
+++ b/qrenderdoc/Windows/MainWindow.cpp
@@ -37,7 +37,9 @@
......
debian/watch
View file @ 491d3735
......@@ -15,5 +15,5 @@ repacksuffix=+dfsg,\
repack,compression=xz,\
pgpsigurlmangle=s/(.+)\/archive\/(\S+)\.tar\.gz/$1\/releases\/download\/$2\/$2.tar.gz.asc/ \
https://github.com/baldurk/swig/tags \
.*/renderdoc-modified-(\d+)\.tar\.gz 5
# change 5 on previous line if renderdoc-modified-6 swig is released
.*/renderdoc-modified-(\d+)\.tar\.gz 6
# change 6 to 7 on previous line if renderdoc-modified-7 swig is released
docs/CONTRIBUTING.md 0 → 100644
View file @ 491d3735
# Contributing to RenderDoc
This document is split up and organised into several sections to aid reading and linking. For small changes like one-line fixes or minor tweaks then you can just read the [quick start section](#quick-start) below.
Don't worry about reading all of these documents end-to-end and getting everything perfect the first time. The point of this information isn't to be restrictive about rules and reject contributions, but to give people guidance and help about how to contribute. I'm happy to help out with any changes needed to get your PR ready to merge, until you get the hang of things. If you're unfamiliar with git and need help making any changes, feel free to ask as well!
If you're a regular contributor or if you have a larger amount of code to change, please do read through these as it will make life easier for everyone if you to follow along with these guidelines from the start.
## Code of Conduct
I want to ensure that anyone can contribute to RenderDoc with only the next bug to worry about. For that reason the project has adopted the [contributor covenent](CODE_OF_CONDUCT.md) as a code of conduct to be enforced for anyone taking part in RenderDoc development. This includes any comments on issues or any public discussion e.g. in the #renderdoc IRC channel.
If you have any queries or concerns in this regard you can get in touch with me [directly over email](mailto:baldurk@baldurk.org).
## Copyright / Contributor License Agreement
Any code you submit will become part of the repository and be distributed under the [RenderDoc license](../LICENSE.md). By submitting code to the project you agree that the code is your own work and that you have the ability to give it to the project.
You also agree by submitting your code that you grant all transferrable rights to the code to the project maintainer, including for example re-licensing the code, modifying the code, distributing in source or binary forms. Specifically this includes a requirement that you assign copyright to the project maintainer (Baldur Karlsson). For this reason, do not modify any copyright statements in files in any PRs.
## Contributing information
1. [Dependencies](CONTRIBUTING/Dependencies.md)
2. [Compiling](CONTRIBUTING/Compiling.md)
3. [Preparing commits](CONTRIBUTING/Preparing-Commits.md)
4. [Developing a change](CONTRIBUTING/Developing-Change.md)
5. [Testing](CONTRIBUTING/Testing.md)
6. [Code Explanation](CONTRIBUTING/Code-Explanation.md)
## Quick Start
The two things you'll need to bear in mind for a small change are the [commit message](CONTRIBUTING/Preparing-Commits.md#commit-messages) and [code formatting](CONTRIBUTING/Preparing-Commits.md#code-formatting).
Commit messages should have a first line with a **maximum of 72 characters**, then a gap, then if you need it a longer explanation in any format you want. The reason for this is that limiting the first line to 72 characters means that `git log` and github's history always displays the full message without it being truncated.
For more information, check the section about [commit messages](CONTRIBUTING/Preparing-Commits.md#commit-messages).
Code should be formatted using **clang-format 3.8**. The reason we fix a specific version of clang-format is that unfortunately different versions can format code in different ways using the same config file, so this would cause problems with automatic verification of code formatting.
For more information, check the section about [code formatting](CONTRIBUTING/Preparing-Commits.md#code-formatting).
docs/CONTRIBUTING/Code-Explanation.md 0 → 100644
View file @ 491d3735
# Code Explanation
There are [several pages](https://github.com/baldurk/renderdoc/wiki/Code-Dives) on the wiki explaining different aspects of how the code fits together - like how the capture-side works vs replay-side, how shader debugging works, etc.
renderdoc/
CMakeLists.txt ; The cmake file, will recurse into subdirectories to build them
renderdoc.sln ; VS2015 solution for windows building
renderdoc/
3rdparty/ ; third party utilities & libraries included
drivers/ ; API-specific back-ends, can be individually skipped/removed
... ; everything else in here consists of the core renderdoc runtime
renderdoccmd/ ; A small C++ utility program that runs to do various little tasks
renderdocshim/ ; A tiny C DLL using only kernel32.dll that is used for global hooking
qrenderdoc/ ; The Qt UI layer built on top of renderdoc/
docs/ ; source documentation for the .chm file or http://docs.renderdoc.org/
util/ ; folder for utility/support files - e.g. build scripts, installers, CI config
docs/CONTRIBUTING/Compiling.md 0 → 100644
View file @ 491d3735
# Compiling
## Windows
The main [renderdoc.sln](renderdoc.sln) is a VS2015 solution. It should also compile in VS2017, just select to update the compilers if you don't have the 2015 compilers available.
There are no external dependencies apart from the Windows SDK and any version will work, otherwise all libraries/headers needed to build are included in the git checkout.
On windows, the `Development` configuration is recommended for day-to-day dev. It's debuggable but not too slow. The `Release` configuration is then obviously what you should compile for any builds you'll send out to people or if you want to evaluate performance.
## Linux
First check that you have all of the [required dependencies](Dependencies.md#linux).
Currently linux should work with gcc 5+ and clang 3.4+ as it requires C++14 compiler support. The Travis CI builds with gcc-6.0 and clang-3.5. Within reason other compilers will be supported if the required patches are minimal. Distribution packages should be built with the `Release` CMake build type so that warnings do not trigger errors. To build just run:
```
cmake -DCMAKE_BUILD_TYPE=Debug -Bbuild -H.
make -C build
```
Configuration is available for cmake, [documented elsewhere](https://cmake.org/documentation/). You can override the compiler with environment variables `CC` and `CXX`, and there are some options you can toggle in the root CMakeLists files such as `cmake -DENABLE_GL=OFF`.
## Mac
First check that you have all of the [required dependencies](Dependencies.md#mac).
Mac support is pretty early and while it will compile, it's not usable for debugging yet and is not officially supported. Builds happen with cmake the same way as Linux.
## Android
First check that you have all of the [required dependencies](Dependencies.md#android).
To build the components required to debug an Android target invoke cmake and enable `BUILD_ANDROID=On`:
```
mkdir build-android
cd build-android
cmake -DBUILD_ANDROID=On -DANDROID_ABI=armeabi-v7a ..
make
```
On Windows, you need to specify the 'generator' type to the cmake invocation. The exact parameter will depend on your bash shell, but options are e.g. `-G "MSYS Makefiles"` or `-G "MinGW Makefiles"`, i.e.:
```
cmake -DBUILD_ANDROID=On -DANDROID_ABI=armeabi-v7a -G "MSYS Makefiles" ..
```
### Note:
With GLES programs on Android, the built-in hooking method doesn't always work. If you have trouble with crashes or problems capturing GLES programs, try enabling building with [interceptor-lib](../../renderdoc/3rdparty/interceptor-lib/README.md). **WARNING**: Building this requires a hefty dependency.
docs/CONTRIBUTING/Dependencies.md 0 → 100644
View file @ 491d3735
# Dependencies
## Windows
On Windows there are no dependencies - you can always compile the latest version just by downloading the code and compiling the solution in Visual Studio. If you want to modify the Qt UI with a WYSIWYG editor you will need a version of Qt installed - at least version 5.6.
## Linux
Requirements for the core library and renderdoccmd are `libx11`, `libxcb`, `libxcb-keysyms` and `libGL`. The exact are packages for these vary by distribution.
For qrenderdoc you need Qt5 >= 5.6 along with the 'svg' and 'x11extras' packages. You also need `python3-dev` for the python integration, and `bison`, `autoconf`, `automake` and `libpcre3-dev` for building the custom SWIG tool for generating bindings.
This is the apt-get line you'd need to install the requirements bar Qt on Ubuntu 14.04 or above:
```
sudo apt-get install libx11-dev libx11-xcb-dev mesa-common-dev libgl1-mesa-dev libxcb-keysyms1-dev cmake python3-dev bison autoconf automake libpcre3-dev
```
Your version of Ubuntu might not include a recent enough Qt version, so you can use [Stephan Binner's ppas](https://launchpad.net/~beineri) to install a more recent version of Qt. At least 5.6.2 is required. If you choose to instead install an [official Qt release](https://download.qt.io/official_releases/qt/) or build Qt from source, add `-DQMAKE_QT5_COMMAND=/path/to/qmake` to your cmake arguments.
For Archlinux (as of 2017.04.18) you'll need:
```
sudo pacman -S libx11 libxcb xcb-util-keysyms mesa libgl qt5-base qt5-svg qt5-x11extras cmake python3 bison autoconf automake pcre
```
For Gentoo (as of 2017.04.18), you'll need:
```
sudo emerge --ask x11-libs/libX11 x11-libs/libxcb x11-libs/xcb-util-keysyms dev-util/cmake dev-qt/qtcore dev-qt/qtgui dev-qt/qtwidgets dev-qt/qtsvg dev-qt/qtx11extras sys-devel/bison sys-devel/autoconf sys-devel/automake dev-lang/python dev-libs/libpcre
```
Checking that at least Qt 5.6 installs.
On CentOS 7 (as of 2018.01.18), you'll need to install from several repos:
```
# Dependencies in default repo
yum install libX11-devel libxcb-devel mesa-libGL-devel xcb-util-keysyms-devel cmake qt5-qtbase-devel qt5-qtsvg-devel qt5-qtx11extras-devel bison autoconf automake pcre-devel
# python3 via EPEL
yum install epel-release
yum install python34-devel
# Newer GCC via SCL's devtoolset-7
yum install centos-release-scl
yum install devtoolset-7
```
Then when building, you must first set up the devtoolset-7 from SCL:
```
scl enable devtoolset-7 bash
```
And build within the resulting bash shell, which has the tools first in PATH.
On any distribution if you find qmake isn't available under its default name, or if `qmake -v` lists a Qt4 version, make sure you have qtchooser installed in your package manager and use it to select Qt5. This might be done by exporting `QT_SELECT=qt5`, but check with your distribution for details.
For some distributions such as CentOS, the Qt5 qmake command is `qmake-qt5`. To select this explicitly, pass `-DQMAKE_QT5_COMMAND=qmake-qt5` when invoking `cmake`.
If you know the required packages for another distribution, please share (or pull request this file!)
## Mac
Mac requires a recent version of CMake, and the same Qt version as the other platforms (at least 5.6.2). If you're using [homebrew](http://brew.sh) then this will do the trick:
```
brew install cmake qt5
brew link qt5 --force
```
You will also need `autotools`. That is usually available by default but might need to be explicitly installed with `brew install autotools`.
## Android
To build for Android, you must download components of the Android SDK, the Android NDK, and Java Development Kit.
If you've already got the tools required, simply set the following three environment variables:
```
export ANDROID_SDK=<path_to_sdk_root>
export ANDROID_NDK=<path_to_ndk_root>
export JAVA_HOME=<path_to_jdk_root>
```
Otherwise, below are steps to acquire the tools for each platform.
### Android Dependencies on Windows
JDK can be installed from the following [link](http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html).
```
set JAVA_HOME=<path_to_jdk_root>
```
Android NDK and SDK:
```
# Set up the Android SDK
set ANDROID_SDK=<path_to_desired_setup>
cd %ANDROID_SDK%
wget https://dl.google.com/android/repository/sdk-tools-windows-3859397.zip
unzip sdk-tools-windows-3859397.zip
cd tools\bin
sdkmanager --sdk_root=%ANDROID_SDK% "build-tools;26.0.1" "platforms;android-23"
# Accept the license
# Set up the Android NDK
cd %ANDROID_SDK%
wget http://dl.google.com/android/repository/android-ndk-r14b-windows-x86_64.zip
unzip android-ndk-r14b-windows-x86_64.zip
set ANDROID_NDK=%ANDROID_SDK%\android-ndk-r14b
```
### Android Dependencies on Linux
The Java Development Kit can be installed with:
```
sudo apt-get install openjdk-8-jdk
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
```
The Android SDK and NDK can be set up with the following steps. They are also mirrored in our Travis-CI [setup script](util/travis/android_setup.sh) for Android. We are currently targeting build-tools 26.0.1 and NDK r14b.
SDK links are pulled from [here](https://developer.android.com/studio/index.html).
NDK links are pulled from [here](https://developer.android.com/ndk/downloads/older_releases.html).
```
# Set up Android SDK
export ANDROID_SDK=<path_to_desired_setup>
pushd $ANDROID_SDK
wget http://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
unzip sdk-tools-linux-3859397.zip
cd tools/bin/
./sdkmanager --sdk_root=$ANDROID_SDK "build-tools;26.0.1" "platforms;android-23"
# Accept the license
# Set up Android NDK
pushd $ANDROID_SDK
wget http://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip
unzip android-ndk-r14b-linux-x86_64.zip
export ANDROID_NDK=$ANDROID_SDK/android-ndk-r14b
```
### Android Dependencies on Mac
JDK can be installed with brew:
```
brew cask install java
export JAVA_HOME="$(/usr/libexec/java_home)"
```
Android NDK and SDK:
```
# Set up Android SDK
export ANDROID_SDK=<path_to_desired_setup>
pushd $ANDROID_SDK
wget https://dl.google.com/android/repository/sdk-tools-darwin-3859397.zip
unzip sdk-tools-darwin-3859397.zip
cd tools/bin/
./sdkmanager --sdk_root=$ANDROID_SDK "build-tools;26.0.1" "platforms;android-23"
# Accept the license
# Set up Android NDK
pushd $ANDROID_SDK
wget https://dl.google.com/android/repository/android-ndk-r14b-darwin-x86_64.zip
unzip android-ndk-r14b-darwin-x86_64.zip
export ANDROID_NDK=$ANDROID_SDK/android-ndk-r14b
```
docs/CONTRIBUTING/Developing-Change.md 0 → 100644
View file @ 491d3735
# Developing a change
If you're making a tiny bugfix that only changes a few lines, then you don't really have to worry about how you structure your development or organise branches. You can just make your fix, open up a pull request, and everything can be handled from there on the fly.
When making a larger change though, there are more things to take into consideration. Your changes need to be compatible with the project on a larger scale, as well as making sure your development process can merge into the mainline development with other contributors and the project maintainer.
There are a few guidelines to follow to make sure that everyone can work together with as little friction as possible:
Be proactive about communication. You can always [email me](mailto:baldurk@baldurk.org) about anything RenderDoc related including work you are planning, or currently doing. You can also open an issue to discuss a change. Staying in communication particularly with me can head off problems at a much earlier stage - perhaps a design you were planning would conflict with the direction of the project or with a better idea of the whole picture I can suggest something that would be more appropriate. It's much better to have a conversation and avoid spending time doing work that will be rejected or require rewrites at PR stage.
Aim to merge your work to the main line in reasonably sized chunks. How big is a 'reasonably sized' chunk is debateable, but bear in mind that your code must be able to be reviewed. If in doubt you can always split the work into a smaller standalone chunk, but keeping any one PR under 1000 lines changed at the very most is a good mental limit. Keeping a large change on a branch means that you have to do more merges from the mainline to keep up to date, and increases the chance that your changes will diverge away from the project. The [LLVM developer policy](http://llvm.org/docs/DeveloperPolicy.html#incremental-development) describes this kind of workflow and its benefits much better than I can.
# Where to Start
There are always plenty of things to do, if you'd like to chip in! Check out the [Roadmap](https://github.com/baldurk/renderdoc/wiki/Roadmap) page in the wiki for future tasks to tackle, or have a look at the [issues](https://github.com/baldurk/renderdoc/issues) for outstanding bugs. I'll try and tag things that seem like small changes that would be a good way for someone to get started with.
If you have a change you'd like to see make it into mainline, create a fork of renderdoc, make your changes to a branch, and open a pull request on github. You can look around for instructions on that - it's pretty simple.
Have a clear idea of what your change is to do. This goes hand in hand with the above, but if your change involves a lot of work then it's better to split it up into smaller components that can be developed and merged individually, towards the larger goal. Doing this makes it more easily digestible for the rest of the people on the project as well as making it easier to review the changes when they land.
It's fine to land features one-by-one in different drivers. Historically there have been features that only worked on certain APIs so don't feel that you must implement any new feature on all APIs. At the same time, feature parity is a goal of the project so you should aim to implement features that can be later ported to other APIs where possible either by yourself or by others.
docs/CONTRIBUTING/Preparing-Commits.md 0 → 100644
View file @ 491d3735
# Preparing commits
## Commit Messages
Ensure commit messages have a single title of at most 72 characters, followed by a body if necessary:
```
Short summary text, maximum of 72 characters. That's out to here ---->X
Longer paragraph that details the change and any logic behind needing
to make the change, other impacts, future work etc. Keeping the title
to 72 characters means it will display fully in git log and github logs.
```
Merge commits should **not** be included in pull requests as they just muddy the history. Please use `git rebase` when bringing code up to date against latest `v1.x`.
Likewise commits for code formatting or compile fixes should be squashed into the relevant commits that they update, rather than left in the history.
## Code formatting
To make things easier for everyone, I've adopted clang-format for keeping code consistently formatted.
| :warning: | | :warning: |
| --------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------- |
| :warning: | **Unfortunately clang-format output changes between versions even with the same config.** | :warning: |
| :warning: | **I have fixed the version used for RenderDoc at [clang-format-3.8](http://releases.llvm.org/download.html#3.8.1).** | :warning: |
| :warning: | **This formatting is enforced by CI checks that run on PRs, so if you aren't running the same version locally it will show up there.** | :warning: |
If you want to format a single file, run: `clang-format -i file.cpp`. If you want to format any changes you make before you commit them, you'll need python installed and then run: `git clang-format`. To clang-format the whole codebase, you can run the bash script `util/clang_format_all.sh` but be sure to squash any changes into the right commits.
There are instructions on how to set up git hooks or IDE integration [on the wiki](https://github.com/baldurk/renderdoc/wiki/Code-formatting-(using-clang-format)).
All intermediate commits should follow the formatting conventions. Having several intermediate commits with mismatched formatting then a single 'reformatted code' commit at the end makes history harder to read, which is an important tool for others to understand your code. It is much easier to enforce proper formatting on each commit as you go along, than to try and untangle and merge formatting changes in after the fact.
Since it's not covered by a pure formatting check, don't use overly modern C++ unnecessarily. Although the minimum compiler spec is now higher than it was in the past (as of March 2017) and modern features may be supported, some modern C++ constructs do not fit with the style of the rest of the code.
## Branch history
Different people have different preferences on how history should be organised. Some people prefer to commit often and then squash down changes into a single commit after they've finished working. Others prefer to combine commits intermittently when they reach a logical boundary and or next step. Some like to avoid committing until they have a 'final' commit that they are ready to make.
I'm flexible about whether branches are squashed or expanded when they are put up for PR. The history should be reasonable though; if you have a change that modifies a dozen files and changes hundreds of lines of code then it should not be squashed into a single commit. Likewise, intermittent changes where something was tried and then reverted, or minor fixes and tweaks as you go should be rebased and squashed together to form a more coherent whole. As a rule of thumb, try to keep your commit messages describing what they do roughly, even if it is a minor change. Commit messages like "fix stuff" or "compile fix" or any message with "WIP", "amend", "temp", etc should probably not remain in the final PR.
With fixes from a code review it's up to you whether you keep changes as a separate commit or squash them in. With the exception of formatting and compile fix commits, which as noted before should be squashed into the relevant commits.
For overall scope of a change/branch read the [developing a change](Developing-Change.md) section.
docs/CONTRIBUTING/Testing.md 0 → 100644
View file @ 491d3735
# Testing
At the moment the testing of any features and changes is pretty much ad-hoc. I've been working on a proper test suite that will test both API capture/replay support as well as the analysis features.
Until then, test any changes you make around the area that you've tested - if I have any particular suggestions on testing I will probably bring it up in the pull request.
docs/Makefile
View file @ 491d3735
......@@ -6,20 +6,12 @@ SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
PAPER ?=
BUILDDIR ?= ../Documentation
HHCBUILD ?= "/C/Program Files (x86)/HTML Help Workshop/hhc.exe"
# User-friendly check for sphinx-build
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don\'t have Sphinx installed, grab it from http://sphinx-doc.org/)
endif
# check for hhc as well
ifeq ($(shell which $(HHCBUILD) >/dev/null 2>&1; echo $$?), 0)
HAS_HHCBUILD = 1
else
HAS_HHCBUILD = 0
endif
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
......@@ -35,7 +27,6 @@ help:
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " applehelp to make an Apple Help Book"
@echo " devhelp to make HTML files and a Devhelp project"
......@@ -93,25 +84,7 @@ json:
.PHONY: htmlhelp
htmlhelp:
$(SPHINXBUILD) -b htmlhelp -t htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
# Copy handwritten index file to output, overwriting auto-generated one
@cp renderdoc.hhk $(BUILDDIR)/htmlhelp
# Copy introduction page over index.html
@cp $(BUILDDIR)/htmlhelp/introduction.html $(BUILDDIR)/htmlhelp/index.html
# Filter out the auto-generated TOC to remove anchor links and root index.html
@cat $(BUILDDIR)/htmlhelp/renderdoc.hhc | python remove_lines.py ".html#" | python remove_lines.py "\"index.html\"" > $(BUILDDIR)/htmlhelp/tmp
@mv $(BUILDDIR)/htmlhelp/tmp $(BUILDDIR)/htmlhelp/renderdoc.hhc
ifeq ("$(HAS_HHCBUILD)","1")
-$(HHCBUILD) $(BUILDDIR)/htmlhelp/renderdoc.hhp
@echo "Build finished."
else
@echo $(HHCBUILD)
@echo "Build finished; now you can run HTML Help Workshop with the " \
".hhp project file in $(BUILDDIR)/htmlhelp."
@echo "For future, you can either install HTML Help Workshop to the " \
"default path [C:\Program Files (x86)\HTML Help Workshop] or " \
"set the variable HHCBUILD to the path to hhc.exe."
endif
@echo "htmlhelp build is only supported through make.sh"
.PHONY: qthelp
qthelp:
......
docs/behind_scenes/d3d12_support.rst
View file @ 491d3735
......@@ -20,7 +20,6 @@ RenderDoc has initial support for D3D12, but it contains some caveats. In additi
* RenderDoc assumes that even if multiple GPUs are present, that only one will be used - i.e. NodeMask is always 0. Multiple queues are supported.
* RenderDoc captures may not be portable between different systems, only currently supporting capture and replay on the same or similar enough machines.
* Reserved resources are not supported.
* Multisampled resources will be blank at the start of a frame, regardless of what contents were there during capture.
* Shared resources/handles are not supported.
* Pixel history is not implemented.
* Shader debugging is not currently supported.
......
docs/behind_scenes/vulkan_support.rst
View file @ 491d3735
......@@ -38,7 +38,6 @@ RenderDoc has support for Vulkan version 1.1, as well as a number of extensions,
* Sparse textures are only supported for non-arrayed 2D textures with no mips.
* Pixel history is not implemented.
* Shader debugging is not currently supported.
* Mesh output of geometry/tessellation shader stages is not available.
Android
-------
......