Hello Team,
I’m working on a mobile title built, with Vulkan enabled we’ve been seeing random GPU crashes (VK_ERROR_DEVICE_LOST / app process killed by GPU driver) primarily on:
- Samsung Galaxy S24 Ultra – SM-S928B, Adreno 750, Android 14-16
- Also seen on a smaller on Pixel 10 Pro and some other recent devices
The same build is stable on older devices (e.g. Galaxy S23 Ultra / Adreno 740).
To investigate, we packaged a development build, rut it with -gpuvalidation and collected several crash logs. These runs consistently show Vulkan validation errors in UE’s mobile rendering paths just before the crash. I’m attaching three representative logs:
First case -
2025-11-18 17:51:56: [ 43]LogVulkanRHI: Warning: *** [Error:Validation(UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout)] Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x79df57e850, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x6a01b90000001a81, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkCmdDraw(): command buffer VkCommandBuffer 0x79df57e850[] expects VkImage 0x6a01b90000001a81[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
Second case -
[2025.11.24-10.57.08:303][ 0]LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkGraphicsPipelineCreateInfo-Input-07904)] Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-Input-07904 ] Object 0: handle = 0xca56f0000000517, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0xcc9c32be | vkCreateGraphicsPipelines(): pCreateInfos[0].pVertexInputState->pVertexAttributeDescriptions does not have a Location 1 but vertex shader has an input variable at that Location. The Vulkan spec states: If the pipeline is being created with vertex input state and pVertexInputState is not dynamic, then all variables with the Input storage class decorated with Location in the Vertex Execution Model OpEntryPoint must contain a location in VkVertexInputAttributeDescription::location (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-Input-07904)
Third case -
[2025.11.21-15.40.41:305][601]LogVulkanRHI: Warning: *** [Error:Validation(VUID-vkCmdDraw-viewType-07752)] Validation Error: [ VUID-vkCmdDraw-viewType-07752 ] Object 0: handle = 0xffd71b00000677b8, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0xb4462a000006590b, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0x73ed4ff5 | vkCmdDraw(): the descriptor VkDescriptorSet 0xffd71b00000677b8[] [Set 1, Binding 6, Index 0, variable “MobileReflectionCapture_Texture”] ImageView type is VK_IMAGE_VIEW_TYPE_2D but the OpTypeImage has (Dim = Cube) and (Arrayed = 0). The Vulkan spec states: If a VkImageView is accessed as a result of this command, then the image view’s viewType must match the Dim operand of the OpTypeImage as described in Instruction/Sampler/Image View Validation (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdDraw-viewType-07752)
Crash behaviour
- All three errors occur only on Vulkan, and these 3 cases are on Adreno 750. The same content is stable on older Adreno GPUs.
- The crash is hard to reproduce; it happens at difference places and once out of 10/15 tests.
Any guidance or known fixes for these Vulkan validation issues on mobile would be greatly appreciated, as they appear to be the only hard clues we have for the random device-lost crashes on Adreno 750.
Note: Builds with -gpucrashdebugging and r.Android.SupportsTimestampQueries 1 didn’t give any additional information about the crashes.
[Attachment Removed]
Hi Levan,
Can you see if -gpucrashdebugging yields any more information? Additionally, can you confirm driver versions on the offending Adreno 750 devices?
Best regards.
[Attachment Removed]
Hello [Content removed]
As I mentioned in the report -gpucrashdebugging doesn’t give any additional information.
I tested two S24 devices, one with Android 14 and another with Android 16.
SRC_AndroidVersion: 14
SRC_GLVersion: OpenGL ES 3.2 V[Content removed] 1704277645) (Date:01/03/24)
API=1.3.128 (0x403080) Driver=0x802e8012 VendorId=0x5143
SRC_AndroidVersion: 16
SRC_GLVersion: OpenGL ES 3.2 V[Content removed] 1750408231) (Date:06/20/25)
API=1.3.128 (0x403080) Driver=0x802fa027 VendorId=0x5143
You can find these details in the log files I attached to the report.
[Attachment Removed]
Hi Levan,
We believe this may be related to driver updates in which validation warnings (which all appear to be valid) may have shifted to cause crashes internally to the driver. Is providing sample repro possible or is this rare enough that it only repros within the scope of your application?
Best regards
[Attachment Removed]
Hello Stephane,
Thanks for the insight. Unfortunately, the crash is non-deterministic and hard to reproduce reliably. It typically occurs once every 10-15 runs and at different places.
At this time, we haven’t been able to create a minimal standalone repro, the issue only reproduces under the full application workload.
Best regards
[Attachment Removed]
Hi Levan,
Do you happen to recall if any of these validations errors actually occured on Adreno based platforms where no device loss/driver/gpu crash occur?
Best regards.
[Attachment Removed]
Hello [Content removed]
I found in logs (run with -gpuvalidation) of these devices Validation Errors
Samsung S23 Ultra (CPU SM-S918B, GPU Adreno ™ 740)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkSubpassDescription2-attachment-06912)] Validation Error: [ VUID-VkSubpassDescription2-attachment-06912 ] | MessageID = 0x4e59d47a | vkCreateRenderPass2KHR(): pCreateInfo->pSubpasses[1].pInputAttachments[0].layout (VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL) is invalid.
The Vulkan spec states: If the attachment member of an element of pInputAttachments is not VK_ATTACHMENT_UNUSED, its layout member must not be VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkSubpassDescription2-attachment-06912)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkGraphicsPipelineCreateInfo-Input-07904)] Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-Input-07904 ] Object 0: handle = 0x2063e600000004cd, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0xcc9c32be | vkCreateGraphicsPipelines(): pCreateInfos[0].pVertexInputState->pVertexAttributeDescriptions does not have a Location 1 but vertex shader has an input variable at that Location. (This can be valid if vertexAttributeRobustness feature is enabled).
The Vulkan spec states: If vertexAttributeRobustness is not enabled and the pipeline is being created with vertex input state and pVertexInputState is not dynamic, then all variables with the Input storage class decorated with Location in the Vertex Execution Model OpEntryPoint must contain a location in VkVertexInputAttributeDescription::location (https://docs.vulkan.org/spec/latest/chapters/pipelines.html#VUID-VkGraphicsPipelineCreateInfo-Input-07904)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkImageMemoryBarrier2-oldLayout-01212)] Validation Error: [ VUID-VkImageMemoryBarrier2-oldLayout-01212 ] Object 0: handle = 0xede7ca0000000328, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4636ad61 | vkCmdPipelineBarrier2KHR(): pDependencyInfo->pImageMemoryBarriers[0].newLayout (VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL) is not compatible with VkImage 0xede7ca0000000328[] usage flags VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT.
The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, and oldLayout or newLayout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL then image must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkImageMemoryBarrier2-oldLayout-01212)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-vkCmdCopyImageToBuffer-srcImage-00186)] Validation Error: [ VUID-vkCmdCopyImageToBuffer-srcImage-00186 ] Object 0: handle = 0x7492f90ff0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xede7ca0000000328, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x30009145 | vkCmdCopyImageToBuffer(): srcImage (VkImage 0xede7ca0000000328[]) was created with VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT but requires VK_IMAGE_USAGE_TRANSFER_SRC_BIT.
The Vulkan spec states: srcImage must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag (https://docs.vulkan.org/spec/latest/chapters/copies.html#VUID-vkCmdCopyImageToBuffer-srcImage-00186)
-Samsung S21 FE (CPU: SM-G990B2, GPU: Adreno ™ 660)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkSubpassDescription2-attachment-06912)] Validation Error: [ VUID-VkSubpassDescription2-attachment-06912 ] | MessageID = 0x4e59d47a | vkCreateRenderPass2KHR(): pCreateInfo->pSubpasses[1].pInputAttachments[0].layout (VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL) is invalid.
The Vulkan spec states: If the attachment member of an element of pInputAttachments is not VK_ATTACHMENT_UNUSED, its layout member must not be VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkSubpassDescription2-attachment-06912)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkGraphicsPipelineCreateInfo-Input-07904)] Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-Input-07904 ] Object 0: handle = 0x18223200000004c1, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0xcc9c32be | vkCreateGraphicsPipelines(): pCreateInfos[0].pVertexInputState->pVertexAttributeDescriptions does not have a Location 1 but vertex shader has an input variable at that Location. (This can be valid if vertexAttributeRobustness feature is enabled).
The Vulkan spec states: If vertexAttributeRobustness is not enabled and the pipeline is being created with vertex input state and pVertexInputState is not dynamic, then all variables with the Input storage class decorated with Location in the Vertex Execution Model OpEntryPoint must contain a location in VkVertexInputAttributeDescription::location (https://docs.vulkan.org/spec/latest/chapters/pipelines.html#VUID-VkGraphicsPipelineCreateInfo-Input-07904)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkImageMemoryBarrier-oldLayout-01212)] Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01212 ] Object 0: handle = 0xed385f0000000325, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xff795e16 | vkCmdPipelineBarrier(): pImageMemoryBarriers[0].newLayout (VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL) is not compatible with VkImage 0xed385f0000000325[] usage flags VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT.
The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, and oldLayout or newLayout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL then image must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkImageMemoryBarrier-oldLayout-01212)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-vkCmdCopyImageToBuffer-srcImage-00186)] Validation Error: [ VUID-vkCmdCopyImageToBuffer-srcImage-00186 ] Object 0: handle = 0x762eaef090, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xed385f0000000325, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x30009145 | vkCmdCopyImageToBuffer(): srcImage (VkImage 0xed385f0000000325[]) was created with VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT but requires VK_IMAGE_USAGE_TRANSFER_SRC_BIT.
The Vulkan spec states: srcImage must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag (https://docs.vulkan.org/spec/latest/chapters/copies.html#VUID-vkCmdCopyImageToBuffer-srcImage-00186)
[Attachment Removed]
Honor Magic V (CPU: MGI-AN00, GPU: Adreno ™ 730)
2026-01-16 14:23:48: [ 0]LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkSubpassDescription2-attachment-06912)] Validation Error: [ VUID-VkSubpassDescription2-attachment-06912 ] | MessageID = 0x4e59d47a | vkCreateRenderPass2KHR(): pCreateInfo->pSubpasses[1].pInputAttachments[0].layout (VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL) is invalid.
2026-01-16 14:23:48: The Vulkan spec states: If the attachment member of an element of pInputAttachments is not VK_ATTACHMENT_UNUSED, its layout member must not be VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkSubpassDescription2-attachment-06912)
2026-01-16 14:23:48: [ 0]LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkGraphicsPipelineCreateInfo-Input-07904)] Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-Input-07904 ] Object 0: handle = 0x3cd02200000004d1, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0xcc9c32be | vkCreateGraphicsPipelines(): pCreateInfos[0].pVertexInputState->pVertexAttributeDescriptions does not have a Location 1 but vertex shader has an input variable at that Location. (This can be valid if vertexAttributeRobustness feature is enabled).
2026-01-16 14:23:48: The Vulkan spec states: If vertexAttributeRobustness is not enabled and the pipeline is being created with vertex input state and pVertexInputState is not dynamic, then all variables with the Input storage class decorated with Location in the Vertex Execution Model OpEntryPoint must contain a location in VkVertexInputAttributeDescription::location (https://docs.vulkan.org/spec/latest/chapters/pipelines.html#VUID-VkGraphicsPipelineCreateInfo-Input-07904)
LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkImageMemoryBarrier2-oldLayout-01212)] Validation Error: [ VUID-VkImageMemoryBarrier2-oldLayout-01212 ] Object 0: handle = 0xee72ed0000000327, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4636ad61 | vkCmdPipelineBarrier2KHR(): pDependencyInfo->pImageMemoryBarriers[0].newLayout (VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL) is not compatible with VkImage 0xee72ed0000000327[] usage flags VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT.
The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, and oldLayout or newLayout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL then image must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkImageMemoryBarrier2-oldLayout-01212)
[542]LogVulkanRHI: Warning: *** [Error:Validation(VUID-vkCmdCopyImageToBuffer-srcImage-00186)] Validation Error: [ VUID-vkCmdCopyImageToBuffer-srcImage-00186 ] Object 0: handle = 0x76dc2fefc0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xee72ed0000000327, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x30009145 | vkCmdCopyImageToBuffer(): srcImage (VkImage 0xee72ed0000000327[]) was created with VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT but requires VK_IMAGE_USAGE_TRANSFER_SRC_BIT.
The Vulkan spec states: srcImage must have been created with VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag (https://docs.vulkan.org/spec/latest/chapters/copies.html#VUID-vkCmdCopyImageToBuffer-srcImage-00186)
[Attachment Removed]
Hi Levan,
There have been a variety of fixes to validation errors similar to the ones mentioned since the 5.5 release, but it is difficult to pinpoint exactly which one. It is my recollection that you app is on the forward renderer, is that correct? Additionally, does -gpubreadcrumbs yield any information in the log when the device loss occurs?
Best regards.
[Attachment Removed]
Hello Stephane
- Yes, the app is on the forward renderer.
- Here is the log of the crash with -gpubreadcrumbs. Check attachments for the full log file.
[2026.01.26-10.37.07:337][101]LogVulkanRHI: Warning: *** [Error:Validation(VUID-VkDescriptorImageInfo-imageLayout-00344)] Validation Error: [ VUID-VkDescriptorImageInfo-imageLayout-00344 ] Object 0: handle = 0x7a4229f1b0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x1c330d000006bf63, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xde55a405 | vkCmdDrawIndexed(): Cannot use VkImage 0x1c330d000006bf63[] (layer=0 mip=0) with specific layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL that doesn’t match the previous known layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL.
The Vulkan spec states: imageLayout must match the actual VkImageLayout of each subresource accessible from imageView at the time this descriptor is accessed as defined by the image layout matching rules (https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html\#VUID\-VkDescriptorImageInfo\-imageLayout\-00344\)
[2026.01.26-10.37.07:339][101]LogVulkanRHI: Warning: *** [Error:Validation(VUID-vkCmdDrawIndexed-None-08114)] Validation Error: [ VUID-vkCmdDrawIndexed-None-08114 ] Object 0: handle = 0x584f5f0000071ba6, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0x3f6fd836 | vkCmdDrawIndexed(): Descriptor set VkDescriptorSet 0x584f5f0000071ba6[] Image layout specified by vkCmdBindDescriptorSets doesn’t match actual image layout at time descriptor is used. See previous error callback for specific details.
The Vulkan spec states: Descriptors in each bound descriptor set, specified via vkCmdBindDescriptorSets, must be valid as described by descriptor validity if they are statically used by the VkPipeline bound to the pipeline bind point used by this command and the bound VkPipeline was not created with VK_PIPELINE_CREATE_DESCRIPTOR_BUFFER_BIT_EXT (https://docs.vulkan.org/spec/latest/chapters/drawing.html\#VUID\-vkCmdDrawIndexed\-None\-08114\)
Best regards.
[Attachment Removed]
Hi Levan,
Do you have parallel RHI translation enabled? Wondering if that may be affecting it as 730+ devices would have the necessary Vulkan Extensions to do so. Otherwise, is falling back to GLES a possibility?
Best regards.
[Attachment Removed]
Hi Stephane,
I checked the Parallel RHI translation setting.
We don’t have an explicit override for r.RHICmd.ParallelTranslate.Enable in our config or device profiles.
In a development build, querying via console shows it is enabled by default: r.RHICmd.ParallelTranslate.Enable = true
Next step: force r.RHICmd.ParallelTranslate.Enable=0 and rerun testing on the affected Adreno 750 devices to see if it changes the behavior.
If we can’t get a stable Vulkan path on these devices, we can consider switching to OpenGL ES as a workaround, but this will probably mean that all the devices should run OpenGL, as we’ve already moved all the Mali GPUs to OpenGL because of another
Vulkan crash - [Content removed]
[Attachment Removed]
Hi Levan,
Assuming your product’s min spec includes older GLES only devices, is there any particular Vulkan feature that your higher spec devices benefit from? Or would moving to GLES across the full device spectrum maintain parity vs. the Vulkan version?
Best regards.
[Attachment Removed]
Hello Stephane,
I can answer that: we still use Vulkan on some devices because we see that it provides better performance on modern GPUs compared to GLES. For example, we observed a significant performance drop when we moved Adreno 650 from Vulkan to GLES.
Also, some devices like the Xclipse 530 have visual artifacts and crashes on GLES, while on Vulkan it is much more stable.
Kind regards
[Attachment Removed]
Thanks Alexander,
That makes sense, thanks for the details. Xclipse chips are indeed interesting. They do not have a native GL driver, but rather use ANGLE on VK. I’ll ping development again about these issues; unfortunately, lack of a repro project and reliable repro path within your app makes it challenging to iron out where this is originating from. If you do end up with any reliable repro, please advise.
Best regards.
[Attachment Removed]
Hello Stephane,
Quick update on r.RHICmd.ParallelTranslate.Enable: I ran several tests with r.RHICmd.ParallelTranslate.Enable=0, but I’m still seeing crashes.
Best Regards.
[Attachment Removed]
Thanks Levan,
Has this issue been seen on any Adreno 8xx series devices at all? Trying to narrow down a driver range.
Best regards.
[Attachment Removed]
Hello Stephane,
I tested on a Samsung Galaxy S25 (Adreno 830), and I wasn’t able to reproduce the crash.
Best regards
[Attachment Removed]
Hi Levan,
Does this issue occur in specific area of your application? We believe this may be getting triggered by certain types of materials. I may be worth exploring this and if it is a material issue, to narrow which one may be triggering the offense.
Best regards/
[Attachment Removed]
Hello [Content removed]
I ran several tests with different materials disabled. Eventually, this resulted in a black screen, but the crashes still reproduced. However, after setting r.PSOPrecaching=0 while keeping all materials enabled, the crashes no longer reproduce (so far). Do you know of any approach or command that would show in the logs which PSOs are being compiled/precached at the time of the crash (i.e., what specifically triggers it when PSO precaching is enabled)?
Best regards
[Attachment Removed]