renderdoc что это за программа
Renderdoc что это за программа
Администратор 
Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1
Блог компании Инфопульс Украина,
Game Development*,
Анимация и 3D графика*
Как вы, возможно, знаете в мире Windows для рисования графики часто используется DirectX. В последних версиях (10, 11.x) библиотека серьёзно шагнула вперёд и именно на них построены движки многих современных игр. Кроме того, DirectX используется не только в играх — сам интерфейс ОС Windows тоже с непомню-какой версии (Vista?) рисуется через него, да и казалось-бы не сильно связанные с графикой программы, желая увеличить производительность и плавность зумаскрола переходят на последние версии DirectX. Так некоторое время назад на DirectX11 перешел рендер Google Chrome (вроде бы с версии 36).
Когда-то во времена Windows 95 и Pentium II была такая шутка, что чем медленнее компьютер — тем лучше можно понять работу операционной системы — невооруженным глазом видно в каком порядке прорисовываются элементы окон, обрабатываются события. Сегодня для подобных целей относительно DirectX есть отдельные инструменты — графические отладчики, позволяющие понять, как именно рисуется каждый пиксель каждого кадра, какие операции выполняет движок DirectX, какие ресурсы он использует, насколько быстро и правильно всё работает. Один из таких инструментов — RenderDoc от компании Crytek мы сегодня и рассмотрим. А в качестве примера разберём уже упомянутый выше новый рендер Google Chrome.
Прежде всего — почему я говорю о RenderDoc? Есть немало аналогичных инструментов:
Все они — очень хороши. Но:
Что касается RenderDoc, то это:
Итак, качаем RenderDoc, устанавливаем. Запускаем, видим главное окно. Открываем в меню Tools->Options и указываем папку, в которую будут складываться временные файлы (дампы).
Теперь нам нужно запустить под отладчиком RenderDoc приложение, которое мы хотим отлаживать. Для этого на вкладке «Capture Executable» вводим путь к Chrome, его рабочую папку. Здесь есть несколько интересных моментов. Графика в Хроме рисуется в отдельном дочернем процессе, его можно определить запустив Process Hacker и найдя среди всех запущенных процессов chrome.exe тот, у которого среди параметров командной строки имеется флаг —type=gpu-process.
Мы не можем запустить этот процесс напрямую, поэтому мы должны запустить главный процесс Chrome, указав в RenderDoc, что хотим отслеживать вызовы DirectX-функций в том числе среди дочерних процессов (галочка Hook Into Children)
По-умолчанию дочерние процессы Chrome «живут» в песочнице — имеют низкий Integrity Level, который препятствует их взаимодействию с файловой системой, другими процессами и общими ресурсами ОС. Таким образом, если мы просто запустим Chrome, то RenderDoc не будет в состоянии взаимодействовать с процессом, в котором рисуется графика. Для этого есть хак — Chrome нужно запускать со специальным флагом —no-sandbox, который отключает «песочницу» Chrome.
Поскольку нам интересно вообще всё, что будет происходить по ходу рисования графики — включаем побольше разных полезных галочек. Также мы можем сразу указать, какой по счету фрейм мы хотим захватить (для этого есть галочка Queue Capture Of Frame #), а можем уже в приложении нажать кнопку PrintScreen, чтобы создать дамп для текущего кадра
В итоге вкладка Capture Executable у нас будет выглядеть вот так:
Жмём кнопку Capture, запускается Chrome.
В верхней части окна мы видим некую отладочную информацию, которая говорит нам как-минимум о нескольких вещах:
Теперь можно открыть в Chrome что-нибудь и нажать PrintScreen. В верхней части окна Chrome появится надпись о созданном скриншоте. Всё, Chrome можно закрывать, а в папке, которую вы указали в настройках должен появиться файл с расширением rdc. Это и есть наш дамп. Открываем его через «File->Open Log» и видим примерно вот такую картину:
В верхней части окна находится «таймлайн» — временная линия, на которой отмечены этапы рисования данного кадра. Их может быть до нескольких десятков (если вы их не видите — кликните по плюсику в левом верхнем углу окна «Timeline»). Те же этапы отмечены в панели «Event Browser» в левой части окна. Кликая по таймлайну или по событиям в «Event Browser» мы можем переходить к разным моментам по ходу рисования кадра.
Корневой узел дерева событий называется «Frame #N» и показывает, какой это кадр от момента инициализации DirectX в приложении. Далее следует мета-узел «Frame start» указывающий на момент начала рисования данного кадра (никаких реальных вызовов DirectX-методов к нему не привязано). Далее мы видим три узла: «Colour Pass #1 (1 Targets)«, «Draw(4)» и «Present()«. Из этого мы можем понять, что всё рисование контента окна хрома проходит в несколько этапов:
Как видите, этап рисование в промежуточную текстуру в дереве можно раскрыть и мы увидим моменты рисования отдельных элементов окна Хрома.
Первым делом текстура очищается (вызов ClearRenderTargetView). Затем следует много этапов под названием «DrawIndexed(6)«. 6 — это количество точек, ограничивающих область, рисуемую на данном этапе. То, что их 6, наталкивает на мысль, что это 2 треугольника, составляющих прямоугольник. Давайте выберем один их этапов «DrawIndexed(6)» (не первый, но и не последний) и рассмотрим его повнимательнее.
Начнём с вкладки «Pipeline State«
Как вы, возможно, знаете, в DirectX11 используется понятие «Pipelene» — это набор из нескольких последовательных операций, предназначенных для формирования окончательного кадра. Начинается пайплайн с этапа Input Assembler — здесь мы предоставляем все необходимые входные данные по вершинным, индексным и константным буферам, которые могут в дальнейшем понадобиться для рассчёта что и куда нужно будет рисовать. Далее следуют этапы обработки входных данных различными типами шейдеров и последняя фаза — Output Merger, в которой графика компонуется и выводится туда, куда должна быть выведена.
В окне Pipeline State мы можем кликнуть по любой стадии пайплайна и увидеть:
Перейдя в окно текстур, мы можем увидеть используемые при рисовании данного кадра текстуры:
В тулбаре «PS Resources» мы видим текстуру(ы), которая будет рисоваться на данном этапе, а в тулбаре «OM Targets» — текстуру, куда будет происходить отрисовка. Оставаясь в окне текстур, можно покликать по этапам отрисовке сверху или слева — и мы увидим, что Хром рисует своё окно текстурами размером 256х256 пикселей. Начинает он с нижней части окна, потом рисует боковые края и затем — заголовок окна с тулбарами. После этого Хром приступает к рисованию контента вкладки (опять-таки кусочками по 256х256 пикселей). Потом рисуются лежащие «поверх» контента объекты — видео, флеш-баннеры, всплывающие подсказки. На последних этапах рисуются скроллбар и его ползунок. Теперь текстура готова к рисованию в бэкбуфер.
Что ещё интересного умеет RenderDoc
Показывать API вызываемых DirectX-методов для каждого этапа отрисовки
Невероятно полезная вещь. А учитывая, что видны не только названия методов, но и их параметры — это вообще красота.
Показывать колстек (откуда в коде был вызван тот или иной DirectX-метод)
Правда, для этого нужно подсунуть программе pdb-файл (который у вас есть только если вы сами — автор отлаживаемого кода). Весьма полезно для отладки своих программ, полностью бесполезно для анализа чужих.
Для вершинных шейдеров отладка начинается в окне Mesh Output с клика правой кнопкой мыши по интересующей вершине.
Для пикселей — в окне текстур, где на интересующем пикселе нужно кликнуть правой кнопкой мыши и кликнуть в тулбаре «Pixel Content» кнопку «Debug this Pixel«
RenderDoc — графический отладчик для DirectX11 от Crytek
Как вы, возможно, знаете в мире Windows для рисования графики часто используется DirectX. В последних версиях (10, 11.x) библиотека серьёзно шагнула вперёд и именно на них построены движки многих современных игр. Кроме того, DirectX используется не только в играх — сам интерфейс ОС Windows тоже с непомню-какой версии (Vista?) рисуется через него, да и казалось-бы не сильно связанные с графикой программы, желая увеличить производительность и плавность зумаскрола переходят на последние версии DirectX. Так некоторое время назад на DirectX11 перешел рендер Google Chrome (вроде бы с версии 36).
Когда-то во времена Windows 95 и Pentium II была такая шутка, что чем медленнее компьютер — тем лучше можно понять работу операционной системы — невооруженным глазом видно в каком порядке прорисовываются элементы окон, обрабатываются события. Сегодня для подобных целей относительно DirectX есть отдельные инструменты — графические отладчики, позволяющие понять, как именно рисуется каждый пиксель каждого кадра, какие операции выполняет движок DirectX, какие ресурсы он использует, насколько быстро и правильно всё работает. Один из таких инструментов — RenderDoc от компании Crytek мы сегодня и рассмотрим. А в качестве примера разберём уже упомянутый выше новый рендер Google Chrome.
Прежде всего — почему я говорю о RenderDoc? Есть немало аналогичных инструментов:
Все они — очень хороши. Но:
Что касается RenderDoc, то это:
Итак, качаем RenderDoc, устанавливаем. Запускаем, видим главное окно. Открываем в меню Tools->Options и указываем папку, в которую будут складываться временные файлы (дампы).
Теперь нам нужно запустить под отладчиком RenderDoc приложение, которое мы хотим отлаживать. Для этого на вкладке «Capture Executable» вводим путь к Chrome, его рабочую папку. Здесь есть несколько интересных моментов. Графика в Хроме рисуется в отдельном дочернем процессе, его можно определить запустив Process Hacker и найдя среди всех запущенных процессов chrome.exe тот, у которого среди параметров командной строки имеется флаг —type=gpu-process.
Мы не можем запустить этот процесс напрямую, поэтому мы должны запустить главный процесс Chrome, указав в RenderDoc, что хотим отслеживать вызовы DirectX-функций в том числе среди дочерних процессов (галочка Hook Into Children)
По-умолчанию дочерние процессы Chrome «живут» в песочнице — имеют низкий Integrity Level, который препятствует их взаимодействию с файловой системой, другими процессами и общими ресурсами ОС. Таким образом, если мы просто запустим Chrome, то RenderDoc не будет в состоянии взаимодействовать с процессом, в котором рисуется графика. Для этого есть хак — Chrome нужно запускать со специальным флагом —no-sandbox, который отключает «песочницу» Chrome.
Поскольку нам интересно вообще всё, что будет происходить по ходу рисования графики — включаем побольше разных полезных галочек. Также мы можем сразу указать, какой по счету фрейм мы хотим захватить (для этого есть галочка Queue Capture Of Frame #), а можем уже в приложении нажать кнопку PrintScreen, чтобы создать дамп для текущего кадра
В итоге вкладка Capture Executable у нас будет выглядеть вот так:
Жмём кнопку Capture, запускается Chrome.
В верхней части окна мы видим некую отладочную информацию, которая говорит нам как-минимум о нескольких вещах:
Теперь можно открыть в Chrome что-нибудь и нажать PrintScreen. В верхней части окна Chrome появится надпись о созданном скриншоте. Всё, Chrome можно закрывать, а в папке, которую вы указали в настройках должен появиться файл с расширением rdc. Это и есть наш дамп. Открываем его через «File->Open Log» и видим примерно вот такую картину:
В верхней части окна находится «таймлайн» — временная линия, на которой отмечены этапы рисования данного кадра. Их может быть до нескольких десятков (если вы их не видите — кликните по плюсику в левом верхнем углу окна «Timeline»). Те же этапы отмечены в панели «Event Browser» в левой части окна. Кликая по таймлайну или по событиям в «Event Browser» мы можем переходить к разным моментам по ходу рисования кадра.
Корневой узел дерева событий называется «Frame #N» и показывает, какой это кадр от момента инициализации DirectX в приложении. Далее следует мета-узел «Frame start» указывающий на момент начала рисования данного кадра (никаких реальных вызовов DirectX-методов к нему не привязано). Далее мы видим три узла: «Colour Pass #1 (1 Targets)«, «Draw(4)» и «Present()«. Из этого мы можем понять, что всё рисование контента окна хрома проходит в несколько этапов:
Как видите, этап рисование в промежуточную текстуру в дереве можно раскрыть и мы увидим моменты рисования отдельных элементов окна Хрома.
Первым делом текстура очищается (вызов ClearRenderTargetView). Затем следует много этапов под названием «DrawIndexed(6)«. 6 — это количество точек, ограничивающих область, рисуемую на данном этапе. То, что их 6, наталкивает на мысль, что это 2 треугольника, составляющих прямоугольник. Давайте выберем один их этапов «DrawIndexed(6)» (не первый, но и не последний) и рассмотрим его повнимательнее.
Начнём с вкладки «Pipeline State»
Как вы, возможно, знаете, в DirectX11 используется понятие «Pipelene» — это набор из нескольких последовательных операций, предназначенных для формирования окончательного кадра. Начинается пайплайн с этапа Input Assembler — здесь мы предоставляем все необходимые входные данные по вершинным, индексным и константным буферам, которые могут в дальнейшем понадобиться для рассчёта что и куда нужно будет рисовать. Далее следуют этапы обработки входных данных различными типами шейдеров и последняя фаза — Output Merger, в которой графика компонуется и выводится туда, куда должна быть выведена.
В окне Pipeline State мы можем кликнуть по любой стадии пайплайна и увидеть:
Перейдя в окно текстур, мы можем увидеть используемые при рисовании данного кадра текстуры:
В тулбаре «PS Resources» мы видим текстуру(ы), которая будет рисоваться на данном этапе, а в тулбаре «OM Targets» — текстуру, куда будет происходить отрисовка. Оставаясь в окне текстур, можно покликать по этапам отрисовке сверху или слева — и мы увидим, что Хром рисует своё окно текстурами размером 256х256 пикселей. Начинает он с нижней части окна, потом рисует боковые края и затем — заголовок окна с тулбарами. После этого Хром приступает к рисованию контента вкладки (опять-таки кусочками по 256х256 пикселей). Потом рисуются лежащие «поверх» контента объекты — видео, флеш-баннеры, всплывающие подсказки. На последних этапах рисуются скроллбар и его ползунок. Теперь текстура готова к рисованию в бэкбуфер.
Что ещё интересного умеет RenderDoc
Показывать API вызываемых DirectX-методов для каждого этапа отрисовки
Невероятно полезная вещь. А учитывая, что видны не только названия методов, но и их параметры — это вообще красота.
Показывать колстек (откуда в коде был вызван тот или иной DirectX-метод)
Правда, для этого нужно подсунуть программе pdb-файл (который у вас есть только если вы сами — автор отлаживаемого кода). Весьма полезно для отладки своих программ, полностью бесполезно для анализа чужих.
Дебажить шейдеры
Для вершинных шейдеров отладка начинается в окне Mesh Output с клика правой кнопкой мыши по интересующей вершине.
Для пикселей — в окне текстур, где на интересующем пикселе нужно кликнуть правой кнопкой мыши и кликнуть в тулбаре «Pixel Content» кнопку «Debug this Pixel»
Вот такой полезный инструмент RenderDoc.
Удачной вам отладки графики.
RenderDoc
Open Development
I work on RenderDoc myself and you can always contact me with any problems or comments. I’ll respond to you directly and personally, and I’m used to helping people with private or NDA’d projects.
Open Source
RenderDoc is 100% open source and development all happens on github. Check out the source and see how any feature is implemented, report a bug you’ve found, or request a new feature or improvement.
Usability Focus
Usability matters. Tools should have a low barrier to entry and be easy to use and understand. RenderDoc makes the process of getting started as smooth as possible, and simplifies common workflows.
Platform Support
RenderDoc supports Windows 7, 8.x, 10, Linux, Android, and Stadia for capture and replay out of the box. Nintendo Switch™ support is distributed separately for authorized developers as part of the NintendoSDK. Captures are portable between different platforms and hardware.
Customisable
On top of being able to modify the source to change or customise behaviour, RenderDoc embeds the python runtime for progammatic access to frame captures.
Widely Used
RenderDoc is the debugger of choice for many people within the game industry, academia, and hobbyists. Engine-level integration ships in Unity, and in Unreal.
RenderDoc is our #1 tool to track down rendering and compute issues on PC: RenderDoc is lightweight and snappy, gives us a concise view of the GPU and its state, and allows us to quickly track down problems!
— Rolando Caloca Olivares (Epic Games)
RenderDoc has been one of the most dependable PC graphical debugging tools for us over the years. Best thing, it’s open source, you can roll-out your own features and contribute fixes.
— Tiago Rodrigues (Ubisoft Montreal)
RenderDoc was instrumental in fixing our DirectX 11 graphics and compute bugs on PC. It is the first tool I open when I need to track down a graphics bug.
— Jamie Hayes (Ready at Dawn)
Screenshots
RenderDoc v1.0 is here! Android support for GLES & Vulkan, Qt UI on windows, and many other improvements.
This version brings some exciting new features:
The fully nitty-gritty and all details are available over on the GitHub release notes, so go check it out and download the build.
As always if you have any questions, comments, or any other kind of feedback you can always reach me by email or on twitter or in the IRC channel. Don’t hesitate to send me a message as I’m always happy to hear from RenderDoc’s users.
Articles
Today is the 5 yr anniversary of the first commit to RenderDoc’s original git repository. I’ve written some nostalgic words about the early days before its first public release.
Vulkan has a lot of really nice concepts, but one that hasn’t had as much attention until now is the layer system that’s built into the API ecosystem.
I’ve written this post with a specific target audience in mind, namely those who have a good grounding in existing APIs (e.g. D3D11 and GL) and understand the concepts of multithreading, staging resources, synchronisation and so on but want to know specifically how they are implemented in Vulkan. So we end up with a whirlwind tour of what the main Vulkan concepts look like.
A series of posts aimed at a technically minded average person, who wants to know more about how modern graphics work. This won’t teach you how to make anything and it doesn’t assume much prior knowledge, but hopefully it will explain the concepts at least.
RenderDoc — графический отладчик для DirectX11 от Crytek
Как вы, возможно, знаете в мире Windows для рисования графики часто используется DirectX. В последних версиях (10, 11.x) библиотека серьёзно шагнула вперёд и именно на них построены движки многих современных игр. Кроме того, DirectX используется не только в играх — сам интерфейс ОС Windows тоже с непомню-какой версии (Vista?) рисуется через него, да и казалось-бы не сильно связанные с графикой программы, желая увеличить производительность и плавность зума\скрола переходят на последние версии DirectX. Так некоторое время назад на DirectX11 перешел рендер Google Chrome (вроде бы с версии 36).
Когда-то во времена Windows 95 и Pentium II была такая шутка, что чем медленнее компьютер — тем лучше можно понять работу операционной системы — невооруженным глазом видно в каком порядке прорисовываются элементы окон, обрабатываются события. Сегодня для подобных целей относительно DirectX есть отдельные инструменты — графические отладчики, позволяющие понять, как именно рисуется каждый пиксель каждого кадра, какие операции выполняет движок DirectX, какие ресурсы он использует, насколько быстро и правильно всё работает. Один из таких инструментов — RenderDoc от компании Crytek мы сегодня и рассмотрим. А в качестве примера разберём уже упомянутый выше новый рендер Google Chrome.
Итак, качаем RenderDoc, устанавливаем. Запускаем, видим главное окно. Открываем в меню Tools->Options и указываем папку, в которую будут складываться временные файлы (дампы).
Теперь нам нужно запустить под отладчиком RenderDoc приложение, которое мы хотим отлаживать. Для этого на вкладке «Capture Executable» вводим путь к Chrome, его рабочую папку. Здесь есть несколько интересных моментов. Графика в Хроме рисуется в отдельном дочернем процессе, его можно определить запустив Process Hacker и найдя среди всех запущенных процессов chrome.exe тот, у которого среди параметров командной строки имеется флаг —type=gpu-process.
Мы не можем запустить этот процесс напрямую, поэтому мы должны запустить главный процесс Chrome, указав в RenderDoc, что хотим отслеживать вызовы DirectX-функций в том числе среди дочерних процессов (галочка Hook Into Children)
По-умолчанию дочерние процессы Chrome «живут» в песочнице — имеют низкий Integrity Level, который препятствует их взаимодействию с файловой системой, другими процессами и общими ресурсами ОС. Таким образом, если мы просто запустим Chrome, то RenderDoc не будет в состоянии взаимодействовать с процессом, в котором рисуется графика. Для этого есть хак — Chrome нужно запускать со специальным флагом —no-sandbox, который отключает «песочницу» Chrome.
Поскольку нам интересно вообще всё, что будет происходить по ходу рисования графики — включаем побольше разных полезных галочек. Также мы можем сразу указать, какой по счету фрейм мы хотим захватить (для этого есть галочка Queue Capture Of Frame #), а можем уже в приложении нажать кнопку PrintScreen, чтобы создать дамп для текущего кадра
В итоге вкладка Capture Executable у нас будет выглядеть вот так:
Жмём кнопку Capture, запускается Chrome.
Теперь можно открыть в Chrome что-нибудь и нажать PrintScreen. В верхней части окна Chrome появится надпись о созданном скриншоте. Всё, Chrome можно закрывать, а в папке, которую вы указали в настройках должен появиться файл с расширением rdc. Это и есть наш дамп. Открываем его через «File->Open Log» и видим примерно вот такую картину:
В верхней части окна находится «таймлайн» — временная линия, на которой отмечены этапы рисования данного кадра. Их может быть до нескольких десятков (если вы их не видите — кликните по плюсику в левом верхнем углу окна «Timeline»). Те же этапы отмечены в панели «Event Browser» в левой части окна. Кликая по таймлайну или по событиям в «Event Browser» мы можем переходить к разным моментам по ходу рисования кадра.
Как видите, этап рисование в промежуточную текстуру в дереве можно раскрыть и мы увидим моменты рисования отдельных элементов окна Хрома.
Первым делом текстура очищается (вызов ClearRenderTargetView). Затем следует много этапов под названием «DrawIndexed(6)«. 6 — это количество точек, ограничивающих область, рисуемую на данном этапе. То, что их 6, наталкивает на мысль, что это 2 треугольника, составляющих прямоугольник. Давайте выберем один их этапов «DrawIndexed(6)» (не первый, но и не последний) и рассмотрим его повнимательнее.
Начнём с вкладки «Pipeline State»
Как вы, возможно, знаете, в DirectX11 используется понятие «Pipeline» — это набор из нескольких последовательных операций, предназначенных для формирования окончательного кадра. Начинается пайплайн с этапа Input Assembler — здесь мы предоставляем все необходимые входные данные по вершинным, индексным и константным буферам, которые могут в дальнейшем понадобиться для рассчёта что и куда нужно будет рисовать. Далее следуют этапы обработки входных данных различными типами шейдеров и последняя фаза — Output Merger, в которой графика компонуется и выводится туда, куда должна быть выведена.
Перейдя в окно текстур, мы можем увидеть используемые при рисовании данного кадра текстуры:
В тулбаре «PS Resources» мы видим текстуру(ы), которая будет рисоваться на данном этапе, а в тулбаре «OM Targets» — текстуру, куда будет происходить отрисовка. Оставаясь в окне текстур, можно покликать по этапам отрисовке сверху или слева — и мы увидим, что Хром рисует своё окно текстурами размером 256х256 пикселей. Начинает он с нижней части окна, потом рисует боковые края и затем — заголовок окна с тулбарами. После этого Хром приступает к рисованию контента вкладки (опять-таки кусочками по 256х256 пикселей). Потом рисуются лежащие «поверх» контента объекты — видео, флеш-баннеры, всплывающие подсказки. На последних этапах рисуются скроллбар и его ползунок. Теперь текстура готова к рисованию в бэкбуфер.
Что ещё интересного умеет RenderDoc
Показывать API вызываемых DirectX-методов для каждого этапа отрисовки
Невероятно полезная вещь. А учитывая, что видны не только названия методов, но и их параметры — это вообще красота.
Показывать колстек (откуда в коде был вызван тот или иной DirectX-метод)
Правда, для этого нужно подсунуть программе pdb-файл (который у вас есть только если вы сами — автор отлаживаемого кода). Весьма полезно для отладки своих программ, полностью бесполезно для анализа чужих.
Дебажить шейдеры
Для вершинных шейдеров отладка начинается в окне Mesh Output с клика правой кнопкой мыши по интересующей вершине.
Для пикселей — в окне текстур, где на интересующем пикселе нужно кликнуть правой кнопкой мыши и кликнуть в тулбаре «Pixel Content» кнопку «Debug this Pixel»
Вот такой полезный инструмент RenderDoc.
Удачной вам отладки графики.