addressing more comments.

Author: gpx1000

en/Building_a_Simple_Engine/Subsystems/06_conclusion.adoc

@@ -67,9 +67,9 @@ While our implementations provide a solid foundation, there are several areas wh
 
 ==== General Improvements
 
-* *Cross-Platform Support*: Ensure the subsystems work across different platforms, with appropriate fallbacks for devices without Vulkan support.
+* *Driver and Platform Coverage*: Test the subsystems across a representative set of Vulkan-capable platforms and drivers (e.g., Windows/Linux, major IHVs, Android, and macOS via MoltenVK). Non-Vulkan fallbacks are out of scope for this tutorial.
 * *Profiling and Optimization*: Add detailed profiling to identify and address performance bottlenecks.
-* *Memory Management*: Implement more sophisticated memory management to reduce fragmentation and improve cache coherency.
+* *Memory Management*: Use allocator suballocation strategies (e.g., Vulkan Memory Allocator or custom pools), batch buffer/image allocations, and group resources by usage to reduce fragmentation and improve cache locality.
 * *Multi-Threading*: Further optimize CPU-side processing with multi-threading where appropriate.
 
 === Integration with Other Engine Systems

en/Building_a_Simple_Engine/Tooling/02_cicd.adoc

@@ -80,27 +80,27 @@ jobs:
 
 When setting up CI/CD for Vulkan projects, consider these specific challenges:
 
-===== 1. Vulkan SDK Installation
+===== Vulkan SDK Installation
 
 Ensure your CI environment has the Vulkan SDK installed. Many CI platforms don't include it by default. In the example above, we used a GitHub Action to install the SDK.
 
-===== 2. GPU Availability in CI Environments
+===== GPU Availability in CI Environments
 
 Most CI environments don't have GPUs available, which can make testing Vulkan applications challenging. Consider these approaches:
 
 * Use software rendering (e.g., SwiftShader) for basic tests
 * Implement a headless testing mode that doesn't require a display
 * Use cloud-based GPU instances for more comprehensive testing
 
-===== 3. Platform-Specific Vulkan Loaders
+===== Platform-Specific Vulkan Loaders
 
 Different platforms handle Vulkan loading differently. Ensure your build system correctly handles these differences:
 
 * Windows: Vulkan-1.dll is typically loaded at runtime
 * Linux: libvulkan.so.1 is loaded at runtime
 * macOS: MoltenVK provides Vulkan support via Metal
 
-===== 4. Shader Compilation
+===== Shader Compilation
 
 Shader compilation can be a complex part of the build process. Consider these approaches:
 

en/Building_a_Simple_Engine/Tooling/03_debugging_and_renderdoc.adoc

@@ -191,7 +191,9 @@ void submit_work(vk::raii::Queue& queue, vk::raii::CommandBuffer& cmd_buffer) {
 
 === Using RenderDoc
 
-RenderDoc is a powerful graphics debugging tool that allows you to capture frames from your application and analyze them in detail. It's particularly useful for Vulkan applications due to its comprehensive support for the API.
+RenderDoc is a graphics frame debugger and capture/analysis tool (not a compiler). It allows you to capture frames from your application and analyze them in detail. It's particularly useful for Vulkan applications due to its comprehensive support for the API.
+
+NOTE: In this section we refer to the Event Browser, Pipeline State, and Resource Inspector panels in RenderDoc. Screenshots should accompany these instructions to show where debug names and labels appear in the UI.
 
 ==== Integrating RenderDoc with Your Application
 
@@ -261,10 +263,10 @@ Once you've captured a frame, you can analyze it in the RenderDoc application. H
 
 To get the most out of RenderDoc:
 
-1. *Use Object Names*: As discussed earlier, naming your Vulkan objects makes them much easier to identify in RenderDoc
-2. *Use Command Buffer Labels*: These appear in RenderDoc's event browser, making it easier to navigate complex frames
-3. *Capture Specific Frames*: Use the in-application API to capture frames where issues occur
-4. *Reduce Workload*: For complex applications, consider disabling features or reducing resolution when debugging
+1. *Use Object Names*: As discussed earlier, naming your Vulkan objects makes them much easier to identify in RenderDoc (you'll see them in the Resource Inspector and Pipeline State views).
+2. *Use Command Buffer Labels*: These appear in RenderDoc's Event Browser and help you navigate to the relevant draw/dispatch quickly.
+3. *Capture the Problem Frame*: Trigger a capture exactly when the issue occurs (via hotkey or the in-application API) to minimize unrelated events and noise.
+4. *Minimize to a Repro*: Create a minimal reproducible scene or toggle features off to isolate the problem. If you reduce resolution, make sure it doesn't alter ordering/timing in a way that hides the bug.
 
 === Combining VK_KHR_debug_utils and RenderDoc