Searched refs:faults (Results 1 – 9 of 9) sorted by relevance
/hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/ |
D | fault_handling.adoc | 26 As the potential faults that could occur will vary between different 41 how the faults are communicated, and expected responses from the application 42 for each of the faults that it can: report. 124 To query the number of current faults and obtain the fault data, call 129 * pname:device is the logical device to obtain faults from. 131 the types of faults to obtain from the implementation, and how those 132 faults should be handled. 135 faults that have been detected by the implementation and may: be 147 pname:maxQueryFaultCount>> faults to be reported by flink:vkGetFaultData. 150 detected one or more faults since the last successful retrieval of fault [all …]
|
D | debugging.adoc | 150 To retrieve diagnostic information about faults that may: have caused device
|
D | devsandqueues.adoc | 462 number of faults that the implementation can: record, to be reported via 465 maximum number of faults that the implementation can: report via a
|
/hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/proposals/ |
D | VK_EXT_device_fault.adoc | 30 - Develop extensions or tools that aim to attribute faults to individual Vulkan 120 Implementations may return information on both page faults generated by invalid 194 1) Should `vkGetDeviceFaultInfoEXT` return multiple faults? 197 possible cause of device loss and not to maintain a log of multiple faults. 198 We anticipate that in cases where a GPU does encounter multiple faults, there 199 is a high probability that the faults would be duplicates, such as those caused 208 3) Do page faults need to report the actual address that was accessed, or 211 *RESOLVED*: Some IHVs hardware reports page faults at page alignment, or 230 6) How should implementors approach extensibility for vendor-specific faults?
|
/hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/appendices/ |
D | VK_EXT_device_fault.adoc | 32 faults which may have caused device loss, and to generate binary crash
|
D | VK_EXT_device_address_binding_report.adoc | 32 Similarly, faults generated by accessing virtual addresses outside the
|
D | vulkanscdeviations.adoc | 131 errors or faults to the application that have been detected but are not 133 These could be runtime failures of the system or application faults that are
|
/hardware/google/gfxstream/common/vulkan/include/vulkan/ |
D | vulkansc_funcs.hpp | 5541 std::vector<VULKAN_HPP_NAMESPACE::FaultData, FaultDataAllocator> & faults = data_.second; in getFaultData() local 5549 faults.resize( faultCount ); in getFaultData() 5550 …<VkBool32 *>( &unrecordedFaults ), &faultCount, reinterpret_cast<VkFaultData *>( faults.data() ) ); in getFaultData() 5566 std::vector<VULKAN_HPP_NAMESPACE::FaultData, FaultDataAllocator> & faults = data_.second; in getFaultData() local 5574 faults.resize( faultCount ); in getFaultData() 5575 …<VkBool32 *>( &unrecordedFaults ), &faultCount, reinterpret_cast<VkFaultData *>( faults.data() ) ); in getFaultData()
|
D | vulkansc_raii.hpp | 8396 std::vector<VULKAN_HPP_NAMESPACE::FaultData> & faults = data_.second; in getFaultData() local 8404 faults.resize( faultCount ); in getFaultData() 8405 …<VkBool32 *>( &unrecordedFaults ), &faultCount, reinterpret_cast<VkFaultData *>( faults.data() ) ); in getFaultData()
|