lee/renderdoc
1
0
Fork 0
mirror of https://github.com/baldurk/renderdoc.git synced 2026-05-13 05:20:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update documentation with new minimum requirements for OpenGL

Browse Source
This commit is contained in:
baldurk
2017-01-17 18:59:36 +00:00
parent 80e786427b
commit 86200f1a10
2 changed files with 11 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/behind_scenes/opengl_support.rst
+10 -1
View File
@@ -10,7 +10,16 @@ OpenGL requirements, and limitations
RenderDoc only supports the core profile of OpenGL - from 3.2 up to 4.5 inclusive. This means any compatibility profile functionality will generally not be supported. There are a couple of concessions where it was easy to do so - like allowing the use of VAO 0, or luminance/intensity formats, but this in general will not happen. Note that to be more compatible with applications, RenderDoc will still attempt to capture on an older context, or on a compatibility context, but it will not replay successfully unless the given subset of functionality is used.
RenderDoc assumes your hardware/software configuration is able to create a core 4.3 context for replay, and also that ``EXT_direct_state_access`` and ``ARB_buffer_storage`` are available, both on replay and in capture.
RenderDoc assumes a certain minimum feature set on replay. You must be able to create a 3.2 context with the following extensions available:
* GL_ARB_vertex_attrib_binding
* GL_ARB_program_interface_query
* GL_ARB_shading_language_420pack
* GL_ARB_separate_shader_objects
* GL_ARB_explicit_attrib_location
* GL_ARB_sampler_objects
These extensions should not require newer hardware than the base 3.2 context, but they might need an updated driver to be listed as available. Also note that this is the *minimum* required extension set to replay, various features will be disabled unless you have more capable hardware features such as GL_ARB_shader_image_load_store, GL_ARB_compute_shader and GL_ARB_gpu_shader5.
Regarding multiple contexts and multithreading, RenderDoc assumes that all GL commands (with the exception of perhaps a SwapBuffers call) for frames will come from a single thread, and that all contexts are set up to share objects with each other. This means that e.g. if commands come from a second thread during loading, or some time during initialisation, this will be supported only if the second context shares with the primary context. During frame capture all commands are serialised as if they come from a single thread.
docs/getting_started/faq.rst
+1 -1
View File
@@ -81,7 +81,7 @@ What are the requirements for RenderDoc?
Currently RenderDoc expects Feature Level 11.0 hardware and above for D3D11. Lower levels will capture successfully, but on replay RenderDoc will fall back to WARP software emulation which will run quite slowly.
For OpenGL RenderDoc will only capture core profile applications, in general, and expects to be able to create a core 4.3 context which includes ``EXT_direct_state_access`` and ``ARB_buffer_storage``. For more details see :doc:`../behind_scenes/opengl_support`.
For OpenGL RenderDoc will only capture core profile applications, in general, and expects at minimum to be able to create a core 3.2 context which includes a few key extensions. For more details see :doc:`../behind_scenes/opengl_support`.
With Vulkan, RenderDoc should fully support any Vulkan application. However replaying a Vulkan log may not work if the hardware used to capture it is different - portability of captures between hardware is not guaranteed.