[0001] This patent application claims the benefit of priority to U. S.

Application Serial No. 15/721,273, filed September 29, 2017, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] Embodiments described herein general ly relate to operation of a display engine of an electronic device. Some embodiments described herein generally relate to a fault-tolerant graphics display engine.

BACKGROUND

100031 Buffer under-run is a state occurring when a buffer used to communicate between two devices or processes is fed with data at a lower speed than the data is being read from it. Di splay engine buffer under-run can cause content corruption or unreadability of visual data delivered to a display panel . Thus, techniques for reducing or miti gating for the occurrence of buffer under- run mav be desirable.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In the drawings, which are not necessarily drawn to scale, like numeral s may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

[0005] FIG. 1 illustrates a system in which a fault-tolerant graphi cs di splay engine may be implemented, according to an example;

100061 FIG. 2 illustrates a latency buffer, according to an example;

[0007] FIG. 3 illustrates a flowchart of a first method for identifying and responding to a buffer under- run, according to an example; 100081 FIG. 4 illustrates a flowchart of a second method for identifying and responding to a buffer under-run, according to an example;

[0009] FIG. 5 il lustrates a flowchart of a third method for identifying and responding to a buffer under-run, according to an example; and

[0010] FIG. 6 illustrates a block diagram for an example computer system architecture upon which any one or more of the techniques (e.g., operations, processes, methods, and methodologies) discussed herein may be performed, according to an example. DETAILED DESCRIPTION

[0011] In the following description, methods, configurations, device components, and related apparatuses are disclosed that provide a fault-tolerant graphics display engine for functional safety. Specifically, the following description includes various examples of fault-tolerant graphics display engine hardware and software.

[0012] In an example, the technology described herein provides fault- tolerant graphics di splay engine hardw are for functional safety. The technology described herein may be implemented in any graphics processing environment, for example, a vehicle control display in an autonomous or human-control led vehicle (e.g. surface vehicle, air vehicle, space vehicle, under over water vehicle, or under/ over ground vehicle). The technology described herein may al so be useful in, among other areas, industrial robotics, and medical device/ equipment manufacture and usage.

[0013] In an example, a computer system identifies a buffer under-run at a data buffer (DBUF) of a di splay engine of the computer system. The computer system adjusts a latency tolerance of the DBUF in response to identifying the buffer under-run. The computer system determines that the buffer under-run at the DBU F persi sts after adjusting the latency tolerance. The computer system determines whether a preset correction limit has been reached. If the preset correction limit has not been reached, the computer system further adjusts the latency tolerance of the DBUF. If the preset correction limit has been reached, the computer system removes, from a vi sual output associated with the di splay engine, one or more non-critical display assets. As used herein, the term "engine ^" encompasses its plain and ordinary meaning and may include a component of a computing device including processing hardware and/or memory for carrying out operations. As used herein, the phrase "display engine" encompasses its plain and ordinary meaning and may include a component of a computing device including processing hardware and/or memory for carrying out operations related to a display panel.

|00141 FIG. 1 illustrates a system 100 in which a fault-tolerant graphics display engine may be implemented, according to an example. As shown, the system 100 includes a system memory 105, a display engine 1 15, and a display panel 130.

[0015] The system memory 105 includes a frame buffer 1 10. The frame buffer 1 10 is stored within the system memory 105. The frame buffer 1 10 stores frames to be prov ided to the di splay engine 1 15. The frame buffer 1 10 (or another part of the system memory 105) provides data to be displayed to the di splay engine 1 15.

[0016] The display engine 1 1 5 may be implemented in hardware, software, or a combination of software and hardware. A hardware version of the display engine may include video card(s) or graphics card( s). A software version of the di splay engine may include a client application that decodes video/ graphics. In some examples, the display engine includes both video/ graphics card( s) and the client application that decodes v ideo/ graphics. As shown, the display engine 1 15 includes a DBUF 120 and a processor 125. Data from the system memory 105 and frame buffer 1 10 is buffered at the DBUF 1 20 and eventually provided to the processor 125. The processor 1 25 then outputs the data to the di splay panel 130. The display panel 130 prov ides a visual display of the data to the user. A vi sual output associated with the di splay engine 1 1 5 is provided for display at the display panel 130. The display panel 130 may include one or more of a monitor, a screen, a touchscreen, or the like.

|00171 During buffer under-run, data exits the DBUF 120 (to the processor 125 ) at a faster rate than data enters the DBUF 1 20 (from the system memory 105). Data enters the DBUF 120 at a slower rate than data exits the DBUF (to the process 1 25 ). As a result, the DBUF 120 may become empty. The DBUF 120 becoming empty prevents the processor 1 25 from receiving data from the DBUF 120. This may cause the processor 125 to fail or to prov ide corrupt or unreliable data to the display panel 130. [0018] In some cases, visual data for display is transmitted to the DBUF 120 from the frame buffer 1 10. The DBUF 120 stores the visual data. The DBUF 120 transmits the visual data to the display panel 130 or an intermediate buffer (e.g. processor 125) coupled with processing hardware of the display panel 130. When the DBUF 120 transmits the visual data, the visual data may be removed from the DBUF 120. Eventually, the visual data is provided to the display panel 130 and displayed at the display panel 130. The frame buffer 1 10 and the system memory 105 may reside at the same machine as the display engine 115.

Alternatively, the system memory 105 (which stores the frame buffer 1 10) may be a remote memory, external to a machine housi ng the di splay engine 1 1 5, and connected to that machine via a wired, wirel ess, or network connection. In some examples, the frame buffer 1 10 is stored throughout a volatile or non-volati le memory/ storage hierarchy.

[0019] As noted above, di splay engine buffer under- run may cause content corruption or unreadability (to the user) of an intended visual delivery. Such visual artifacts are dangerous for the functional safety and reliabi lity of mission critical systems, such as autonomous or human-controlled vehicles (e.g. surface vehicle, air vehicle, space vehicle, under/' over water vehicle, or under/ over ground vehicle) and other technology spaces, such as industrial robotics, and medical device/ equipment manufacture and usage. The under-runs may manifest in such vehicles/ systems due to component characteri stic variations caused by changes in atmospheric conditions (e.g. temperature, humidity, radiation, physical movement, etc. ), material or component degradation, manufacturing faults, security breach of software or microcontrollers, or other reasons. Under-run may occur despite proper configuration at system startup initialization. In some cases, there might not be a scheme for automatically overcoming under-run once it occurs. The user may have to rely on debugging or on manual trial -and-error hardware system reconfiguration.

[0020] Some aspects of the technology described herein use hardware mechanisms to adj ust the latency tolerance of the di splay engine buffer. For example, the minimum buffer data lev el to maintain may be adjusted once the under-run i s detected at system run time. Some aspects of the subject technology incorporate the programmable history mechanism of previous automatic hardware correction steps for non-correctable errors. Some aspects of the subject technology include injection of a fatal error message for system logging or diagnostics. As used herein, the phrase "latency tolerance" encompasses its plain and ordinary meaning. A buffer may be more l atency tolerant if it can withstand greater delays in data being written to the buffer, while data is being read from the buffer.

[0021] In some cases, upon display engine buffer under-run, the user notices visual artifacts on the display. The user may then perform manual debug or report issues to the manufacturer to overcome the failures. Some aspects of the technology described herein provide automatic sol utions to display engine buffer under-run, such that the user does not need to rely on manual debugging or reporting issues to the manufacturer. The visual artifacts on the display may be either transient or permanent. In some cases, the artifacts may not be noticed by the user due total loss of information or user not being aware of such information capability. In some cases, critical information may be lost, further potentially causing harm to user due to lack of information (or misinformation) leading to a wrong judgement or deci sion by the user. Thi may be caused by, for example, permanent clipping of the bottom part of display on a black screen without any flickering artifacts caused by the under-run . This case may, in some examples, not give an opportunity to the user to initiate a preliminary manual debug.

[0022 j FIG 2 illustrates a latency buffer 200, according to an example. The latency buffer 200 may correspond to the DBUF 120 of FIG. 1 . As shown, the latency buffer 200 i s filled with data from a source (e.g. the system memory 105) and drains data to a sink (e.g. the processor 125). The latency buffer 200 is designed or programmed to maintain a minimum level of data at all time (for data provision to the sink). This minimum level of data is identified by the minimum level to maintain 205 of the latency buffer 200, which corresponds to the expected latency 2 1 5 of the latency buffer. As shown, the current level 210 of data in the latency buffer 200 is above (greater than) the minimum level (of data in the latency buffer 200) to maintain 205.

[0023] FIG. 3 il lustrates a flowchart of a first method 300 for identifying and responding to a buffer under-run, according to an example.

[0024 j At operation 05, a computing machine (e.g. which includes the system 100 of FIG. 1 ) is powered on. At operation 3 10, a latency tolerance for the computing machine is set. Operation 310 may take place during booting of the computing machine. At operation 315, the computing machine determines whether display engine buffer under-run of the DBUF 120 is detected. If so, the method 300 continues to operation 320. If not, the method 300 continues to operation 325 (skipping operation 320).

[0025] At operation 320, the buffer under-run error is flagged. After operation 320, the method 300 continues to operation 325. In some cases, flagging is not enabled, and operation 320 i s skipped even if there is a buffer under-run.

[0026] At operation 325, after the buffer under- run error is flagged or if there is no buffer under-run, the computing machine continues functioning. At operation 330, the computing machine determines whether there is a display configuration ("config") change. If so, the method 300 returns to operation 310. If not, the method 300 returns to operation 3 1 5. At some point, at operation 335, the computing machine i s powered off.

[0027 J As described in conjunction with FIG. 3, on some hardware, the latency tolerance for the DBUF 120 of the display engine I 1 5 (e.g. the minimum level to maintain 205 ) is set according to the detected configuration during the booting process of the computing machine. Once the computing machine i s booted, during normal operation, if under-run occurs, the di splay engine 1 1 5 continues its normal flow of operations. If error logging or reporting is implemented, errors will be logged or reported. If the di splay configuration changes, then a new latency tolerance may be set. However, the behavior upon buffer under-run may stay the same. Thus, the user viewing the display panel 130 may not have the intended visual experience when under-run happens.

[0028] FIG. 4 illustrates a flowchart of a second method 400 for identifying and responding to a buffer under-run, according to an example.

[0029] At operation 405, a computing machine (e.g. which includes the system 100 of FIG. 1 ) is powered on. At operation 4 10, a latency tolerance for the computing machine is set. Operation 410 may take place during booting of the computing machine. At operation 4 1 5, the computing machine determines whether display engine buffer under-run of the DBUF 120 is detected. Buffer under-run i s a state occurring when a buffer used to communicate between two devices or processes is fed with data at a lower speed than the data i s being read from it. Di splay engine buffer under-run may be detected by comparing the rate at which the di splay engine buffer is fed with data and the rate at which data i s read from the display engine buffer. If the display engine buffer under-run is detected, the method 400 continues to operation 420. If not, the method 400 continues to operation 440.

[0030] At operation 420, upon determining that display engine buffer under- run of the DBUF 120 is detected, the computing machine adjusts the latency tolerance of the DBUF 1 20. In one example, the latency tolerance i s adjusted by increasing the size of the DBUF 120. In one example, the latency tolerance is adjusted by incrementing a minimum level to maintain 205 of the DBUF 1 20, di sabling one or more power management features of the computing machine, or disabling a priority control mechani sm in the computing machine. The latency tolerance may be adjusted by a predetermined amount or percentage. After operation 420, the method 400 continues to operation 425.

[0031] At operation 425, the computing machine determines, once again, whether display engine buffer under-run of the DBUF 120 is detected. If so, the method 400 continues to operation 430. If not the method 400 continues to operation 440.

100321 At operation 430, if display engine buffer under-run of the DBUF 120 is detected at operation 425, the computing machine determines hether the latency tolerance adjustment is less than a preset correction limit. The preset correction limit may correspond to a number of ti mes (e.g. four times) that latency tolerance of the DBUF 120 is adj usted. Alternatively, the preset correction limit may correspond to an amount (e.g. 75%) by which the latency tolerance of the DBUF 1 20 is adj usted from an initial value (set at operation 410) of the latency tolerance of the DBUF. If the latency tolerance adjustment i s less than the preset correction limit, the method 400 returns to operation 420. If the latency tolerance adj ustment i s not less than the preset correction limit, the method 400 continues to operation 435.

[0033] At operation 435, upon determining that the latency tolerance adjustment is not less than the preset correction limit, the computing machine generates an error reporting and diagnostics message. The error reporting and diagnostics message may be provided to the user, so that the user may attempt to fix the error that caused the buffer under-run or may notify the manufacturer of the error. 100341 At operation 440, which occurs after operation 435 or upon failing to detect display engine buffer under- run of the DBUF 120 ad operation 4 1 5 or operation 425, the computing machine continues functioning. At operation 445, the computing machine determines whether there is a display configuration ("config") change. If so, the method 400 returns to operation 410. if not, the method 400 returns to operation 4 1 5. At some point, at operation 450, the computing machine is powered off. After the computing machine is powered off, in some cases, the latency tolerance returns to its original value. Alternatively, the latency tolerance may remain at the new value. In some cases, the latency tolerance returns to its original value and the new value i s stored such that, if buffer under-run is detected again, the latency tolerance may be reset to the new- value.

[0035] As described in conjunction with FIG. 4, the latency tolerance for the di splay buffer is initially set during the booting process of the computing machine. However, at the occurrence of display engine under-run during the runtime of the computing machine, the latency tolerance i s adj usted. For example, the minimum level to maintain 205 is incremented or the priority is increased in another way. The history of prior correction(s) is stored in memory through the correction iteration count. If the threshold of correction iterations is not met, the latency i s further adjusted in subsequent operations and the computing machine checks if the under- run failure is eliminated in each iteration . Once the threshold of correction iterations is met, if the under-run still persi sts, an error reporting and diagnostic message is generated. This message may be used to initiate a system configuration check, fall back to an alternative system, or take other measures.

10036] The programmable latency adjustment operations in the method 400 (e.g. increasing the minimum level to maintain 205 ) and the threshold of correction iterations allow flexibility in various implementations of the method. Some hardware implementations of the method 400 have low latency and high security, and rely on few resources. The method may al so be implemented in software, for example, using a di splay microcontroller or a power controller running firmware code.

[0037] FIG. 5 illustrates a flowchart of a third method 500 for identifying and responding to a buffer under-run, according to an example. 100381 At operation 510, a computing machine (e.g. which includes the system 100 of FIG. 1) identifies a buffer under-run at a DBUF of a display engine. Prior to operation 510, the computing machine may be booted and a latency tolerance of the DBUF may be set to an initial value during the booting of the computing machine. The initial value may be programmed into the computing machine, for example, by a manufacturer of the computing machine. Alternatively, the latency tolerance may correspond to a latency tolerance of the computing machine from immediately before it was powered off.

[0039] At operation 520, the computing machine adjusts the latency tolerance of the DBUF in response to identifying the buffer under-run.

Techniques for adjusting the latency tolerance are described in conjunction with the operation 420 of FIG. 4.

[0040] At operation 530, the computing machine determines that the buffer under-run at the DBUF persists after adjusting the latency tolerance.

[0041] At operation 540, the computing machine determines whether a preset correction limit has been reached. The preset correction limit may correspond to a number of adjustments of the latency tolerance (e.g. six adjustments) or an amount by which the latency tolerance is adj usted (e.g. by 90% from its initial value, so that if the latency tolerance was initially 100ms, it may be adjusted up to 190ms). In some cases, the computing machine determines whether the preset correction limit has been reached by comparing a counter, stored in memory, with the preset correction limit. If the counter i s greater than or equal to the preset correction limit, the computing machine determines that the preset correction limit has been reached. If the counter i s less than the preset correction limit, the computing machine determines that the preset correction limit has not been reached.

100421 If the preset correction limit has not been reached, the method 500 continues to operation 550. If the preset correction limit has not been reached, the method 500 continues to operation 560.

10043] At operation 550, if the preset correction limit has not been reached, the computing machine further adjusts the latency tolerance of the DBUF After operation 550, the method 500 ends.

[0044] At operation 560, if the preset correction limit has been reached, the computing machine removes, from a visual output associated w ith the display engine, one or more non-critical display assets. The computing machine may also generate an error reporting and diagnostics message (e.g. for output or display to the user). A configuration check of the computing machine may be initiated in response to the error reporting and diagnostics message. In some cases, after disabling the non-critical display assets the computing machine checks for under-run, as described in conjunction with FIG. 4. The error reporting/ diagnostic message that is generated during the flow may inform the user regarding the error and encourage the user to maintain caution before taking further follow on measures (e.g. diagnostics, repairs, manufacturer replacement, or the like). Having the error reported again after the configuration change/ from fallback/ alternate system/ diagnostic may indicate the existence of a

catastrophic error to user. After operation 560, the method 500 ends.

[0045] In some examples, a visual output associated with the display engine is provided for display at the display panel. The visual output may include one or more non-critical display assets and one or more critical display assets. The one or more critical display assets may include one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation data, vehicle-to- vehicle communication data, and vehi cl e-to-i nfrastructure communication data. The one or more non-critical display assets may include one or more of: display features, control items, and infotainment icons, functions or features. A list of critical and non-critical display assets may be programmed into the computing machine by its manufacturer, its developer, or a user. Critical display assets are important to the functioning of the machine (e.g., camera and vehicle-to-vehicle communication data in a motor vehicle), whereas non-critical display assets add value to the functioning of the machine but are not mi ssion critical (e.g., an infotainment system or passenger entertainment system in a motor vehicle).

[0046] FIG. 6 is a block diagram illustrating a machine in the example form of a computing system (e.g., computing device) 600, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an example

embodiment. The machine may be a personal computer (PC), a tablet PC, a hybrid tablet/notebook PC, a personal digital assi stant (PDA ), a mobile telephone or smartphone, a wearable computer, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is il lustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0047] Example computer system 600 includes at least one processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory 604 and a static memory 606, which communicate with each other via an interconnect 608 (e.g., a link, a bus, etc. ). The processors ) 602 of the computer system 600 are hardware processors and may correspond to processing hardware of the machine. One or more processors 602 may correspond to a hardware processor array. The computer system 600 may further include a video di splay unit 6 10, an alphanumeric input device 6 12 (e.g., a keyboard), and a user interface (UI) navigation device 6 14 (e.g., a mouse). In one embodiment, the video display unit 610, input device 6 12 and UI navigation device 6 14 are incorporated into a touch screen di play. The computer system 600 may additionally include a storage device 6 16 (e.g., a drive unit), a signal generation device 6 1 8 (e.g., a speaker), an output controller 632, a network interface device 620 (w hich may- include or operably communicate with one or more antennas 628, transceivers, or other w ireless communications hardware), and one or more sensors 630, such as a global positioning system (GPS) sensor, compass, accelerometer, location sensor, or other sensor.

100481 The storage device 6 16 i ncludes a machine-readable medium 622 on which i s stored one or more sets of data structures and instructions 624 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herei n. The instructions 624 may also reside, completely or at least partial ly, within the main memory 604, static memory 606, and/or within the processor 602 during execution thereof by the computer system 600, with the main memory 604, static memory 606, and the processor 602 also constituting machine-readable media.

[0049] While the machine-readable medium 622 is illustrated in an example embodiment to be a singl e medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 624. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium ^" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include nonvolatile memory, including but not limited to, by way of example,

semiconductor memory devices (e.g., electrical ly programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD- ROM disks.

[0050] The instructions 624 may further be transmitted or received over a communications network 626 via an antenna 628 using a transmi ssion medium via the network interface device 620 utilizing any one of a number of well- known transfer protocol s (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone service (POTS) networks, and wireless data networks (e.g., Wi-Fi, 2G/3G, 4G LTE/LTE-A, 5G or WiMAX networks). The term "transmission medium ^" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

[0051] Embodiments used to facilitate and perform the techniques described herein may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non-transitory mechanism for storing

information in a form readable by a machine (e.g., a computer). For example, a machine-readable storage device may include read-only memory (ROM), random-access memory ( RAM ), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.

[0052] It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. S ch components may be embodied by any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other di screte components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physical ly located together, but may comprise disparate instructions stored in different locations which, hen joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

[0053] Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be di stributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized w ithin any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electroni c signals on a system or network . The components or modules may be passive or active, including agents operable to perform desired functions. 100541 Additional examples of the presently described method, system, and device embodiments include the following, non-limiting configurations. Each of the following non-limiting examples may stand on its ow n, or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure.

10055] Example 1 is a system for implementing fault-tolerant graphics, the system comprising: processing hardware of a machine; and a memory device storing instructions which, when executed by the processing hardware, cause the processing hardware to: identify, at the processing hardware, a buffer under-run at a data buffer (DBUF) of a di splay engine; adjust a latency tolerance of the DBUF in response to identifying the buffer under-run; determine that the buffer under-run at the DBUF persists after adj usting the latency tolerance, determine whether a preset correction limit has been reached; if the preset correction limit has not been reached : further adjust the latency tolerance of the DBUF; and if the preset correction limit has been reached: remove, from a visual output associated with the display engine, a non-critical di splay asset.

100561 In Example 2, the subject matter of Example 1 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: boot the machine, wherein the latency tolerance of the DBUF is set to an initial value during booting the machine.

[0057] In Example 3, the subject matter of Examples I 2 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: if the preset correction limit has been reached: generate an error reporting and diagnostics message. 100581 In Example 4, the subject matter of Examples 1 -3 includes, wherein the instructions to adj ust the latency tolerance of the DBUF comprise instructions to increase a size of the DBUF

10059] In Example 5, the subject matter of Examples 1-4 includes, wherein the instructions to adjust the latency tolerance of the DBUF comprise instructions to increment a minimum level to maintain of the DBUF.

100601 In Example 6, the subject matter of Examples 1 -5 includes, wherein the preset correction limit corresponds to a number of times the latency tolerance of the DBUF is adj usted.

[0061] In Example 7, the subject matter of Examples I -6 includes, wherein the preset correction limit corresponds to an amount by which the latency tolerance of the DBUF is adjusted from an initial value of the latency tolerance of the DBUF.

[0062] In Example 8, the subject matter of Examples 1 -7 includes, wherein the non-critical display asset comprises one or more of: display features, control items, and infotainment icons, functions or features.

[0063 j In Example 9, the subject matter of Examples I 8 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: provide the visual output associated with the display engine for display at a display panel .

[0064] In Example 10, the subject matter of Example 9 includes, wherein the visual output comprises the non-critical display asset and a critical display asset.

[0065] In Example I 1 , the subject matter of Example 10 includes, wherein the critical display asset compri ses one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation data, vehicle-to-vehicle communication data, and vehi cl e-to-i nfrastructu re communication data.

[0066] In Example 12, the subject matter of Examples 1-1 1 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: cause transmission, to the DBUF and from a frame buffer, of vi sual data for display; store the visual data at the DBUF; and cause transmission, from the DBUF to a di splay panel or an intermediate buffer coupled ith processing hardware of the display panel, of the visual data for display at the display panel .

[0067] In Example 13, the subject matter of Example 1 2 includes, wherein the frame buffer is stored in the memory device.

[0068] In Example 14, the subject matter of Examples 12-13 includes, wherein the frame buffer is stored in a remote memory, external to the machine.

100691 In Example 15, the subject matter of Examples 1 2- 14 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: remove the visual data from the DBUF in response to transmission of the vi sual data to the di splay panel

[0070 j In Example 16, the subject matter of Examples I 1 5 includes, the display engine; and the DBUF residing within the display engine. [0071] Example 17 is a display engine for implementing fault-tolerant graphics, the display engine comprising: a data buffer (DBUF) stored in a memory device; and a display engine processor to: identify a buffer under-run at the DBUF; adjust a latency tolerance of the DBUF in response to identifying the buffer under-run; determine that the buffer under-run at the DBUP persi sts after adjusting the latency tolerance; determine whether a preset correction limit has been reached; if the preset correction limit has not been reached: further adjust the latency tolerance of the DBUF; and if the preset correction limit has been reached: remove, from a visual output associated with the display engine, a non- critical display asset.

[0072] In Example 18, the subject matter of Example 17 includes, wherein the display engine processor is further to: cause transmission of the visual output to a display panel.

[0073] In Example 19, the subject matter of Examples 17- 18 includes, wherein the display engine processor is further to: boot a machine hosting the display engine, wherein the latency tolerance of the DBUF is set to an initial value during booting the machine.

[0074] In Example 20, the subject matter of Examples 17-19 includes, wherein the display engine processor is further to: if the preset correction limit has been reached: generate an error reporting and diagnostics message.

[0075] In Example 2 1 , the subject matter of Examples 17-20 includes, wherein the display engine processor, to adjust the latency tolerance of the DBUF, is to increase a size of the DBUF.

[0076] In Example 22, the subject matter of Examples 17-21 includes, wherein the display engine processor, to adjust the l atency tolerance of the

DBUF, is to increment a minimum level to maintain of the DBUF.

[0077] In Example 23, the subject matter of Examples 17-22 includes, wherein the preset correction limit corresponds to a number of times the latency tolerance of the DBUF is adjusted.

[0078] In Example 24, the subject matter of Examples 1 7-23 includes, wherein the preset correction limit corresponds to an amount by which the latency tolerance of the DBUF is adjusted from an initial value of the latency tolerance of the DBUF [0079] In Example 25, the subject matter of Examples 1 7-24 includes, wherein the non-critical display asset comprises one or more of: display features, control items, and infotainment icons, functions or features.

[0080] In Example 26, the subject matter of Examples 17-25 includes, the memory device further storing instructions which, when executed by the processing hardware, cause the processing hardware to: provide the visual output associated with the display engine for di splay at a display panel.

[0081 ] In Example 27, the subject matter of Example 26 includes, wherein the visual output comprises the non-critical display asset and a critical display asset.

[0082] In Example 28, the subject matter of Example 27 includes, wherein the critical display asset comprises one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation. data, veh i cl e-to-vehi cl e communication data, and vehicle-to-infrastructure communication data.

[0083] In Example 29, the subject matter of Examples 1 7-28 includes, the display engine processor further to: cause transmission, to the DBUF and from a frame buffer, of visual data for display; store the visual data at the DBUF; and cause transmi ssion, from the DBUF to a display panel or an intermediate buffer coupled with processing hardware of the display panel, of the vi sual data for display at the display panel .

[0084] In Example 30, the subject matter of Example 29 includes, wherein the frame buffer is stored in the memory device.

[0085] In Example 31, the subject matter of Examples 29-30 includes, wherein the frame buffer i s stored in a remote memorv, external to a machine hosting the display engine.

[0086] In Example 32, the subject matter of Examples 29-31 includes, the di splay engine processor further to: remove the visual data from the DBUF in response to transmission of the visual data to the display panel .

[0087] Example 3 is a machine-readable medium storing instructions for implementing fault-tolerant graphics which, when executed by processing hardware of a machine, cause the processing hardware to: identify, at the processing hardware, a buffer under-run at a data buffer (DBUF ) of a display engine; adjust a latency tolerance of the DBUF in response to identifying the buffer under-run; determine that the buffer under- run at the DBUF persists after adjusting the latency tolerance; determine whether a preset correction limit has been reached; if the preset correction limit has not been reached: further adjust the latency tolerance of the DBUF; and if the preset correction limit has been reached: remove, from a visual output associated with the display engine, a non- critical display asset,

[0088 j In Example 34, the subject matter of Example 33 includes, storing instructions which, when executed by the processing hardware, cause the processing hardware to: boot the machine, wherein the latency tolerance of the DBUF is set to an initial value during booting the machine.

100891 In Example 35, the subject matter of Examples 33-34 includes, storing instructions which, when executed by the processing hardware, cause the processing hardware to: if the preset correction limit has been reached: generate an error reporting and diagnostics message.

100901 In Example 6, the subject matter of Examples 33-35 includes, wherein the instructions to adjust the latency tolerance of the DBUF comprise instructi ons to increase a size of the DBUF

j 0091 ] In Example 37, the subject matter of Examples 33-36 includes, herein the instructions to adjust the latency tolerance of the DBUF comprise instructions to increment a minimum level to maintain of the DBUF.

[0092] In Example 38, the subject matter of Examples 33-37 includes, herein the preset correction limit corresponds to a number of times the latency tolerance of the DBUF is adjusted.

100931 In Example 39, the subject matter of Examples 33-38 includes, wherein the preset correction limit corresponds to an amount by which the latency tolerance of the DBUF is adjusted from an initial value of the latency tolerance of the DBUF.

100941 In Example 40, the subject matter of Examples 33-39 includes, wherein the non-critical display asset comprises one or more of: display features, control items, and infotainment icons, functions or features.

j 0095 ] In Example 4 1 , the subject matter of Examples 33-40 includes, storing instructions which, when executed by the processing hardware, cause the processing hardware to: provide the vi sual output associated with the di splay engine for display at a display panel . [0096] In Example 42, the subject matter of Example 41 includes, wherein the visual output comprises the non-critical display asset and a critical display asset.

[0097] In Example 43, the subject matter of Example 42 includes, wherein the critical display asset comprises one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation data, vehicle-to-vehicle communication data, and vehi cl e-to-i nfrastructure communication data.

[0098] In Example 44, the subject matter of Examples 33-43 includes, storing instructions which, when executed by the processing hardware, cause the processing hardware to: cause transmission, to the DBUF and from a frame buffer, of visual data for display; store the visual data at the DBUF; and cause transmission, from the DBUF to a display panel or an intermediate buffer coupled with processing hardware of the display panel, of the visual data for display at the display panel.

[00991 In Example 45, the subject matter of Example 44 includes, wherein the frame buffer is stored in the memory device.

[00100] In Example 46, the subject matter of Examples 44-45 includes, wherein the frame buffer is stored in a remote memory, external to the machine.

[00101] In Example 47, the subject matter of Examples 44-46 includes, storing instructions which, when executed by the processing hardware, cause the processing hardware to: remove the visual data from the DBUF in response to transmission of the visual data to the display panel.

|001021 Example 48 is a method for implementing fault-tolerant graphics, the method comprising: identifying, at a machine, a buffer under-run at a data buffer (DBUF) of a displ ay engine; adjusting a l atency tolerance of the DBUF in response to identifying the buffer under-run; determining that the buffer under- run at the DBUF persists after adjusting the latency tolerance; determining whether a preset correction limit has been reached; if the preset correction limit has not been reached: further adjusting the latency tolerance of the DBUF; and if the preset correction limit has been reached: removing, from a visual output associated with the display engine, a non-critical display asset.

[00103] In Example 49, the subject matter of Example 48 includes, booting the machine, wherein the latency tolerance of the DBUF is set to an initial value during booting the machine. [00104] In Example 50, the subject matter of Examples 48-49 includes, if the preset correction limit has been reached : generating an error reporting and diagnostics message.

[00105] In Example 51, the subject matter of Examples 48-50 includes, wherein adjusting the l atency tolerance of the DBUF comprises increasing a size of the DBUF.

[00106] In Example 52, the subject matter of Examples 48-51 includes, wherein adjusting the latency tolerance of the DBUF comprises incrementing a minimum level to maintain of the DBUF.

|001071 In Example 53, the subject matter of Examples 48-52 includes, wherein the preset correction limit corresponds to a number of times the latency tolerance of the DBUF is adj usted.

[00108] In Example 54, the subject matter of Examples 48-53 includes, wherein the preset correction limit corresponds to an amount by which the latency tolerance of the DBUF is adjusted from an initial value of the latency tolerance of the DBUF.

[00109] In Example 55, the subject matter of Examples 48-54 includes, w herein the non-critical di splay asset compri ses one or more of: display features, control items, and infotainment icons, functions or features.

[00110] In Example 56, the subject matter of Examples 48-55 includes, providing the visual output associated with the display engine for di splay at a display panel .

[00111] In Example 57, the subject matter of Example 56 includes, w herein the visual output comprises the non-critical di splay asset and a critical di splay asset.

[001 12| In Example 58, the subject matter of Example 57 includes, wherein the critical di splay asset compri ses one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation data, vehicle-to-vehicle communication data, and vehi cl e-to-i nfrastructure communication data.

[00113] In Example 59, the subject matter of Examples 48-58 includes, causing transmission, to the DBUF and from a frame buffer, of visual data for di splay; storing the visual data at the DBUF; and causing transmi ssion, from the DBUF to a display panel or an intermediate buffer coupled with processing hardware of the di splay panel, of the visual data for display at the display panel . [00114] In Example 60, the subject matter of Example 59 includes, wherein the frame buffer is stored in the memory device.

[00115] In Example 6 1 , the subject matter of Examples 59-60 includes, wherein the frame buffer is stored in a remote memory, external to the machine.

[00116] In Example 62, the subject matter of Examples 59-61 includes, removing the visual data from the DBUF in response to transmission of the visual data to the display panel .

[001 17| Example 63 is a system comprising: processing hardware of a machine; and a memory device storing instructions which, when executed by the processing hardware, cause the processing hardware to perform the method of any of Examples 48-62.

[00118] Example 64 i s a machine-readable medium storing instructions which, when executed by processing hardware of a machine, cause the processing hardware to perform the method of any of Examples 48-62.

[00119] Example 65 is an apparatus for implementing fault-tolerant graphics, the apparatus comprising: means for identifying, at a machine, a buffer under- run at a data buffer ( DBUF) of a display engine; means for adjusting a latency tolerance of the DBUF in response to identifying the buffer under-run; means for determining that the buffer under-run at the DBUF persists after adjusting the latency tolerance; means for determining whether a preset correction limit has been reached; if the preset correction limit has not been reached: means for further adjusting the latency tolerance of the DBUF; and if the preset correction limit has been reached: means for removing, from a visual output associated with the display engine, a non-critical display asset.

[00120] In Example 66, the subject matter of Example 65 includes, means for booting the machine, wherein the latency tolerance of the DBUF is set to an initial value during booting the machine.

[001211 In Example 67, the subject matter of Examples 65-66 includes, if the preset correction limit has been reached: means for generating an error reporting and diagnostics message.

[001 22 | In Example 68, the subject matter of Examples 65-67 includes, herein the means for adjusting the latency tolerance of the DBUF comprises means for increasing a size of the DBUF. [00123] In Example 69, the subject matter of Examples 65-68 includes, wherein the means for adj usting the latency tolerance of the DBUF comprises means for incrementing a minimum level to maintain of the DBUF

[00124] In Example 70, the subject matter of Examples 65-69 includes, herein the preset correction limit corresponds to a number of times the latency tolerance of the DBUF is adjusted.

[00125] In Example 7 1 , the subject matter of Examples 65-70 includes, wherein the preset correction limit corresponds to an amount by which the latency tolerance of the DBUF is adj usted from an initial value of the latency to! erance of the D B UF .

[00126] In Example 72, the subject matter of Examples 65-7 1 includes, wherein the non-critical display asset comprises one or more of: di splay features, control items, and infotainment icons, functions or features.

|001271 In Example 73, the subject matter of Examples 65- 72 includes, means for prov iding the visual output associated with the display engine for display at a di play panel .

[00128] In Example 74, the subject matter of Example 73 includes, wherein the vi sual output compri ses the non-critical display asset and a critical display- asset.

[00129] In Example 75, the subject matter of Example 74 includes, wherein the critical display asset comprises one or more of: vehicle camera data, vehicle sensor data, vehicle speed data, vehicle geolocation. data, v eh i cl e-to-v ehi cl e communication data, and vehicle-to-infrastructure communication data.

[00130] In Example 76, the subject matter of Examples 65-75 includes, means for causing transmission, to the DBUF and from a frame buffer, of visual data for display; means for storing the visual data at the DBUF; and means for causing transmission, from the DBUF to a di splay panel or an intermediate buffer coupled with processing hardware of the display panel, of the visual data for display at the di splay panel .

[001311 In Example 77, the subject matter of Example 76 includes, wherein the frame buffer is stored in the memory device.

[00132] In Example 78, the subject matter of Examples 76- 77 includes, wherein the frame buffer i s stored in a remote memorv, external to the machine. [00133] In Example 79, the subject matter of Examples 76-78 includes, means for removing the visual data from the DBUF in response to transmission of the visual data to the display panel .

[00134] Example 80 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement of any of Examples 1-79.

[00135] Example 8 1 i s an apparatus comprising means to i mplement of any of Examples 1-79.

[00136] Example 82 is a system to implement of any of Examples 1—79. |001 71 Example 83 is a method to implement of any of Examples 1-79.

[00138| In the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate