Do VRAM/Registers get saved when hibernating?

When a computer goes into ACPI S4 state it saves its RAM contents to disk and shuts down.

But what happens to registers, VRAM, or volatile memory inside extension cards or similar?

hibernate

Max Ried

Posted 2013-08-11T09:24:04.800

Reputation: 1 521

Answers

The TL:DR answer to your question is: Not as a part of the hardware/BIOS S4 implementation, though there is nothing stopping the OS/drivers from doing it.

According to the ACPI specification the Operating System is responsible for initializing all system devices to a usable state after restoring from an S4 hibernation.

ACPI Spec page 7-142 "System \ _S4 State":

Devices states are compatible with the current Power Resource states. In other words, all devices are in the D3 state when the system state is S4

The D3 state is defined as:

D3 - Off:
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on. Since device context and power are lost, devices in this state do not decode their addresses lines. Devices in this state have the longest restore times.
All classes of devices define this state.

For the driver to function under Windows (or any OS for that matter) then it will have to allocate any buffers necessary and store some quantity of state information. This will be stored in the OS memory space and thus will be stored in the hibernation file.

The OS knows what devices to initialize and likely just calls the registered driver initialization code which will check whether any state information was saved in its internal buffers and restore the card to a usable state.

This just reiterates that the cards themselves know nothing of how to bring themselves out of hibernation state and come up into their default "power on" state until Windows (through the drivers) tells it otherwise. There is no requirement to store the card registers outside of OS dependent drivers which will get their memory space saved by the hibernation process.

Mokubai

Posted 2013-08-11T09:24:04.800

Reputation: 64 434

If I read you right, the VRAM and other extension cards caches are saved in RAM within their respectives drivers. On exit of hibernation these drivers are in charge to reinstall these extension memory contents. Did I understand you right? – dan – 2013-08-18T21:10:40.663

1That is how my understanding of it works. The OS (and by extension device drivers) have the responsibility for ensuring that all devices are restored to a usable state after a hibernation event. VRAM may not need to be specifically "saved" as VRAM simply stores a representation of what the system wants so it can be recovered by "replaying" the screen drawing process e.g. take this bitmap and draw it here, then draw this line and so on, all things that will be stored in system ram rather than just VRAM. Something similar is true for all other devices/drivers coming out of hibernation. – Mokubai – 2013-08-18T21:23:37.807

SIMPLY WRONG. The default size of the hibernation file (hiberfil.sys) varies depending on the amount of RAM installed on your PC. The VRAM in modern video cards can be as large or larger than the computer's RAM, but doesn't enter into this calculation. If one replaces the video card by one with larger VRAM, Windows will not reallocate hiberfil.sys! The reason for that is of-course that Windows doesn't save VRAM or any other device-memory (unless the device keeps its memory in RAM). – harrymc – 2013-08-19T05:33:33.687

→ harrymc: no needs to shout ☺. This question wasn't flagged as Windows. Perhaps some readers might be waiting an analysis of the behaviour of some different OSes. – dan – 2013-08-19T05:56:47.590

@danielAzuelos: Not shouting, just flagging an error for future readers. Anyone who ever used a 32-bit operating system of any kind should know that a part of the RAM is used as device-memory for drivers, and that the largest part is usually taken for the video-card, which is the reason that a 4 GB computer cannot use the entire 4 GB. The drivers of course don't expect Windows to keep their on-board memory, nor would Microsoft ever agree to support third-party drivers, video or otherwise. I don't think this is (or can be) different for Linux/Mac with thousands of devices to support. – harrymc – 2013-08-19T06:21:30.557

@harrymc at no point did I say that vram itself is stored, but I was trying to emphasize that it is the duty of the OS and drivers to restore it to a usable state. In my last comment I alluded to the OS/drivers already having access to all the data necessary to recreate vram held in system ram thus making it easy to recreate. I will edit my answer in a short while to be a bit more precise in that regard – Mokubai – 2013-08-19T06:36:28.140

@harrymc maybe the last line on my answer was the problem, mentioning the driver memory space could be interpreted to mean vram which was not my intention. I meant the system memory space that the driver uses rather than vram. I am happy to modify fine points like that if you have other suggestions. – Mokubai – 2013-08-19T06:39:21.903

@Mokubai: Your quotes are semi-correct, but not their interpretation. As another example, "the cards themselves know nothing of how to bring themselves out of hibernation" is incorrect. Many modern devices are computers in their own right. For example, a hard disk may incorporate a RAM buffer and therefore need to know the difference between S3 and S4 states. Although it is the driver that serves as conduit for the OS, devices may also do quite a lot. With all the flavors and optimizations of sleep, there are very few sure facts. Even your quotes are nowadays not always (completely) true. – harrymc – 2013-08-19T07:37:59.767

@harrymc from the computer BIOS perspective (be it old BIOS or UEFI) those quotes are correct, the ACPI BIOS does not care whether the card is able to bring itself back to a usable state or store it's own state and that is purely that devices implementation. The ACPI spec dictates that the BIOS does not remember the state of the card going into and out of S4 and so it is up to the card itself and the OS/drivers to make that state usable. I must admit I saw this question from the other side to you, I looked mainly at the BIOS subsystem that deals with going into and out of S4. – Mokubai – 2013-08-19T08:06:15.470

No argument on the BIOS - I entirely agree there with you. My problems are with the OS/driver/device part. You have deleted VRAM from your answer, but it's still somewhat sketchy on this part, although I think I have said enough above for future readers. I suggest we give the matter a rest. – harrymc – 2013-08-19T08:18:28.897

When the computer's execution is interrupted for sleeping, all CPU registers for the current executing thread(s) are saved in system RAM, as is the normal procedure with interrupts. So these are saved with the RAM and can be seamlessly restarted on wake.

Video RAM or VRAM is not saved and will have to be re-generated by the OS when it wakes to refresh the display, which it does automatically. So a black screen might result for an extremely short (usually unnoticeable) time.

If a used extension card is withdrawn during the sleep, the process that is using it will fail after wake, as will any CD-reading software if the CD is withdrawn, or any process using an outstanding Internet connection. What happens then depends on how that process was programmed.

harrymc

Posted 2013-08-11T09:24:04.800

Reputation: 306 093

1Can you cite this? – Max Ried – 2013-08-15T09:46:23.737

No - personal knowledge. – harrymc – 2013-08-15T10:19:39.367

@danielAzuelos: Video RAM is located on the graphics card and its contents are generated either by the card itself or by the CPU. It once resided in RAM and was used to store the frame-buffer in graphics adapters, but is now used less because video cards have become more powerful than the CPU. Windows only saves RAM and not device-memory. – harrymc – 2013-08-17T07:51:16.100

→ harrymc: how is the VRAM content regenerated? If it isn't saved within the process context, how is the graphical context rebuilt? This graphical context, at the time slice of an interrupt, might be the result of millions of elementary operations on the GPU. If this VRAM isn't saved, how this huge set of operations is replayed? – dan – 2013-08-18T21:07:03.523

@danielAzuelos: The graphical device contexts are invalidated and refreshed, even if this takes several minutes. – harrymc – 2013-08-19T05:36:40.980

→ harrymc: how is the global graphical context redrawn if it was the result of many processes drawing their own windows during the last time slice of the scheduler? Does the OS ask them to replay their last graphical context backward to where it was last saved? Who is in charge of this backup which will permit a replay? Is it the OS, the application, the graphical libraries…? – dan – 2013-08-19T06:04:38.717

@danielAzuelos: It is always the application that is in charge of its windows. The only task of the OS is to issue an invalidated message for the window. – harrymc – 2013-08-19T06:25:54.530

→ harrymc: if I read you right, on hybernation exit, an OS should take care to send all processes which may use a graphical context (GC) so they would be able to recreate it. If these processes didn't take care to save thir GC, then the graphical display will be a local garbage (where a GC can't be restored). Is that the real behaviour? If yes, on which kind of OS? – dan – 2013-08-19T10:25:31.677

@danielAzuelos: Display is impossible without a GC (named differently under different OS), which contains all pixels in RAM, so displaying again doesn't require re-computing. For example, when a windows partially eclipses another window and you move the one under so it is fully shown, most graphical managers on most OS will use the bitmap of that window to redisplay without requiring re-computing. The same goes for hibernation. – harrymc – 2013-08-19T13:00:55.667

They are according to wikipedia: S4: Hibernation or Suspend to Disk. All content of main memory is saved to non-volatile memory such as a hard drive, and is powered down. Also according to here.

Specifically it is said:

S3 - "Suspend to RAM"

All power to the cpu is shut off, and the contents of its registers are flushed to RAM, which remains on. In Microsoft Windows, the "Standby" command can be associated with this state if enabled in the BIOS. Because it requires a high degree of coordination between the cpu, chipset, devices, OS, BIOS, and OS device drivers, this system state is the most prone to errors and instability. Pavel Machek has created a small document with some hints how to solve problems with S3. You can find it in the kernel sources at Documentation/power/tricks.txt. S3 is currently not supported by the 2.4.x kernel series in Linux. S4 - "Suspend to Disk"

CPU power shut off as in S3, but RAM is written to disk and shut off as well. In Microsoft Windows, the "Hibernate" command is associated with this state. A variation called S4BIOS is most prevalent, where the system image is stored and loaded by the BIOS instead of the OS. Because the contents of RAM are written out to disk, system context is maintained. For example, unsaved files would not be lost following an S4 transition. S4 is currently not supported by the 2.4.x kernel series in Linux, but you might have good luck with SWSUSP. Some machines offer S4_BIOS whose support is considered to be experimental within Linux/ACPI.

vfbsilva

Posted 2013-08-11T09:24:04.800

Reputation: 356

The original question was about a key storage point in modern computers: the VRAM and all other forms of volatile memory embedded in extension cards. How are they saved? Some VRAM may reach 1Gbyte. – dan – 2013-08-17T13:52:14.057