Dynamically managing memory footprint for tile based rendering

Patent metadata

Field	Value
Publication number	US-9601092-B2
Application number	US-201514662603-A
Country	US
Kind code	B2
Filing date	Mar 19, 2015
Priority date	Mar 19, 2015
Publication date	Mar 21, 2017
Grant date	Mar 21, 2017

Abstract

The introduction of an “out-of-memory” marker in the sorted tile geometry sequence for a tile may aid in handling out-of-memory frames. This marker allows hardware to continue rendering using the original data stream instead of the sorted data stream. This enables use of the original data stream allows the system to continue rendering without requiring any driver intervention. During the visibility generation/sorting phase, the number of memory pages required for storing the data for a rendering pass is continuously tracked. This tracking includes tracking the pages that are required even if the hardware had not run out-of-memory. This information can be monitored by a graphics driver and the driver can provide more memory pages for the system to work at full efficiency.

First claim

What is claimed is:

1. A method comprising:
determining in a hardware processor, whether sufficient storage is available in a memory that stores visibility information to store additional visibility information;
if an out-of-memory condition exists because sufficient storage is not available, continuing to render without storing visibility information during the out-of-memory condition before requiring an agent to resolve the out-of-memory condition; and
proceeding to render without culling primitives for a rendering pass with an out-of-memory condition.

2. The method of claim 1 including resolving an out-of-memory condition, arising in one rendering pass, in a subsequent rendering pass.

3. The method of claim 1 including recording, memory that would have been needed absent the out-of-memory condition.

4. The method of claim 3 including:
while rendering, detecting an out-of-memory condition in a first rendering pass and marking said condition with a marker; and
detecting the marker in another rendering pass.

5. The method of claim 4 including reducing the rendering speed in response to detecting the marker.

6. The method of claim 1 further including monitoring, during visibility generation, an amount of memory needed to store visibility data for a rendering pass and allocating more memory in response to detecting a need for more memory.

7. The method of claim 1 including determining an amount of available memory for storing visibility information.

8. The method of claim 1 including in response to detection of an out-of-memory condition, rendering as if all primitives are visible.

9. The method of claim 1 including rendering without storing visibility information only during a rendering pass in which an out-of-memory condition was detected, while continuing to render while storing visibility information in another rendering pass.

10. One or more non-transitory computer readable media storing instructions executed by a processor to perform a sequence comprising:
determining whether sufficient storage is available in a memory that stores visibility information to store additional visibility information;
if an out-of-memory condition exists because sufficient storage is not available, continuing to render without storing visibility information during the out-of-memory condition before requiring an agent to resolve the out-of-memory condition; and
in response to detection of an out-of-memory condition, rendering as if all primitives are visible.

11. The media of claim 10 , said sequence including resolving an out-of-memory condition, arising in one rendering pass, in a subsequent rendering pass.

12. The media of claim 10 , said sequence including recording, memory that would have been needed absent the out-of-memory condition.

13. The media of claim 12 , said sequence including:
while rendering, detecting an out-of-memory condition in a first rendering pass and marking said condition with a marker; and
detecting the marker in another rendering pass.

14. The media of claim 13 , said sequence including reducing the rendering speed in response to detecting the marker.

15. The media of claim 10 , said sequence further including monitoring, during visibility generation, an amount of memory needed to store visibility data for a rendering pass and allocating more memory in response to detecting a need for more memory.

16. The media of claim 10 , said sequence including determining an amount of available memory for storing visibility information.

17. The media of claim 10 , said sequence including proceeding to render without culling primitives for a rendering pass with an out-of-memory condition.

18. The media of claim 10 , said sequence including proceeding with rendering without storing visibility information only during a rendering pass in which an out-of-memory condition was detected, while continuing to render while storing visibility information in another rendering pass.

19. An apparatus comprising:
a hardware processor to determine, during tile rendering, whether sufficient storage is available in a memory that stores visibility information to store additional visibility information, and if an out-of-memory condition exists because sufficient storage is not available, continue to render without storing visibility information during the out-of-memory condition before requiring an agent to resolve the out-of-memory condition, and proceed to render without culling primitives for a rendering pass with an out-of-memory condition; and
a storage coupled to said processor.

20. The apparatus of claim 19 , said processor to resolve an out-of-memory condition, arising in one rendering pass, in a subsequent rendering pass.

21. The apparatus of claim 19 , said processor to record, memory that would have been needed absent the out-of-memory condition.

22. The apparatus of claim 21 , said processor while rendering detect an out-of-memory condition in a first rendering pass and mark said condition with a marker and detect the marker in another rendering pass.

23. The apparatus of claim 22 , said processor to reduce the rendering speed in response to detecting the marker.

24. The apparatus of claim 19 , said processor to monitor, during visibility generation, an amount of memory needed to store visibility data for a rendering pass and allocate more memory in response to detecting a need for more memory.

25. The apparatus of claim 19 , said processor to determine an amount of available memory for storing visibility information.

26. The apparatus of claim 19 , said processor in response to detection of an out-of-memory condition, render as if all primitives in a tile are visible.

27. The apparatus of claim 19 , said processor to proceed with rendering without storing visibility information only during a rendering pass in which an out-of-memory condition was detected, while continuing to render while storing visibility information in another rendering pass.

Assignees

• Intel Corp

Inventors

• Apodaca Michael
• Piazza Thomas A
• Poddar Bimal

Classifications

• G06T1/60 Primary

  Memory management · CPC title

• G06T15/005

  General purpose rendering architectures · CPC title

• G09G5/39 Primary

  Control of the bit-mapped memory · CPC title

• G06T15/40

  Hidden part removal · CPC title