Render doc что это за программа
990x.top
Простой компьютерный блог для души)
RenderDoc что это за программа?
Всем привет. Сегодня я решил разобраться с программой RenderDoc — я покопаюсь в интернете и все выясню. Так, вот читаю, что RenderDoc это мощный графический отладчик, который работает с прогами Windows, которые в свою очередь используют графический интерфейс Direct3D 11.0 или 11.1 (или может новее). Значит этот отладчик позволяет проводить детальный анализ картинки для нахождения ошибок и всяких косяков программ. Короче я не совсем понимаю что за отладчик, но ясно одно — простому юзеру это вряд ли нужно будет.
Блин, вот смотрю на RenderDoc и вечно путаю с другой прогой — RocketDock.
Вот еще читаю, что изначально RenderDoc был создан для того чтобы им пользовались разработчики, которые работают с 3D-движком CryENGINE 3 
Загрузить RenderDoc можно с официального сайта CryENGINE. Создатель RenderDoc — компания Crytek.
Так, вот один чел написал интересный коммент, а ну посмотрите:
Вот тот же чел еще написал полезную инфу:
Ребята нашел еще такую инфу:
В общем я думаю что теперь понятно что такое RenderDoc. Но прога явно для спецов, обычному юзеру она просто не нужна будет
Нашел картинку, это прога RenderDoc, она открыта и тут куча всего непонятного, вообще столько много кнопок, каких-то показателей:
И то ребята, это я вам показал не всю картинку, ибо она очень большая и тут ничего не было бы видно. Вот еще одна картина похожего содержания, вообще ничего непонятно:
А вот это в проге 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 an invaluable graphics debugging tool that I use almost every working day. There are many other graphics debugging tools out there, but RenderDoc is the application that I turn to first and use the most. My favourite feature is its HLSL vertex, pixel and compute shader debugging, which has helped me to find and fix countless bugs.
— Kevin Hoque (Creative Assembly)
I use RenderDoc all the time when I’m debugging DirectX code. It’s my go-to tool for personal and work projects.
— Elizabeth Baumel (Disbelief)
RenderDoc is an absolute life saver. Not only has it made graphics debugging for both DX11 and DX12 quicker and easier, but the simple integration API has made it invaluable for testing!
— Neil Forbes-Richardson (Wargaming Sydney)
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.
Render doc что это за программа
Администратор 
Группа: Главные администраторы
Сообщений: 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.
Удачной вам отладки графики.