Re: VRAM vs suspend.
On Mon, 2 Jun 2008 11:25:58 +0200 Matthias Hopf <[EMAIL PROTECTED]> wrote: > On May 31, 08 18:31:45 +0200, Jerome Glisse wrote: > > On Sat, 31 May 2008 14:53:22 +0100 > > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote: > > > > At least on suspend to RAM many GPUs can probably be programmed to keep > > > > VRAM contents alive. In that case you wouldn't have to save that data > > > > as well. > > > You have to deal with it for suspend to disk, so it's a problem that > > > needs solving regardless. You'll also reduce power consumption if you > > > don't need to keep the VRAM powered. > > Also from discussion i did have keeping vram powered isn't reliable > > accross device it will depends on manufacturer and likely with no > > easy to guess out. > > Agreed with StD and reliability. I don't think power consumption is too > high, especially as it will save quite some time during suspend & resume > (no swapping to main memory, no potential swapping of main memory to > disk first for freeing up space). > You'll only know after measuring, though... > > Matthias > Well i think a good plan is to do the normal path where we evict evrythings and copy to main memory. Once we get that working reliably then we can start experimenting with such path. This will likely make suspend/resume faster. I think we can also easly test how much power the card use when in sleep state. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On May 30, 08 20:43:39 +0200, Stefan Dösinger wrote: > Am Freitag, 30. Mai 2008 19:57:32 schrieb Matthias Hopf: > > At least on suspend to RAM many GPUs can probably be programmed to keep > > VRAM contents alive. In that case you wouldn't have to save that data > > as well. > It's a bit far fetched and probably out of question here, but Direct3D has > the > concept of a "lost device" for cases like that. Whenever the video memory AFAIR this concept has been nuked with D3D10, because it created too many issues with the 3D clients. AFAIK You get a "lost device" also if you changed from a fullscreen 3D app to the desktop. > Now OpenGL doesn't have that, apps rely on opengl to restore their textures. > However, it might be an option to add an extension which allows apps to tell > the GL implementation that it can deal with lost resources. If non-game apps > like Compiz support this, it would be enough to improve the suspend > performance considerably. Agreed. Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On May 31, 08 18:31:45 +0200, Jerome Glisse wrote: > On Sat, 31 May 2008 14:53:22 +0100 > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote: > > > At least on suspend to RAM many GPUs can probably be programmed to keep > > > VRAM contents alive. In that case you wouldn't have to save that data > > > as well. > > You have to deal with it for suspend to disk, so it's a problem that > > needs solving regardless. You'll also reduce power consumption if you > > don't need to keep the VRAM powered. > Also from discussion i did have keeping vram powered isn't reliable > accross device it will depends on manufacturer and likely with no > easy to guess out. Agreed with StD and reliability. I don't think power consumption is too high, especially as it will save quite some time during suspend & resume (no swapping to main memory, no potential swapping of main memory to disk first for freeing up space). You'll only know after measuring, though... Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Sat, 31 May 2008 14:53:22 +0100 Matthew Garrett <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote: > > > At least on suspend to RAM many GPUs can probably be programmed to keep > > VRAM contents alive. In that case you wouldn't have to save that data > > as well. > > You have to deal with it for suspend to disk, so it's a problem that > needs solving regardless. You'll also reduce power consumption if you > don't need to keep the VRAM powered. > Also from discussion i did have keeping vram powered isn't reliable accross device it will depends on manufacturer and likely with no easy to guess out. Cheers, Jerome Glisse <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote: > At least on suspend to RAM many GPUs can probably be programmed to keep > VRAM contents alive. In that case you wouldn't have to save that data > as well. You have to deal with it for suspend to disk, so it's a problem that needs solving regardless. You'll also reduce power consumption if you don't need to keep the VRAM powered. -- Matthew Garrett | [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
Am Freitag, 30. Mai 2008 19:57:32 schrieb Matthias Hopf: > At least on suspend to RAM many GPUs can probably be programmed to keep > VRAM contents alive. In that case you wouldn't have to save that data > as well. It's a bit far fetched and probably out of question here, but Direct3D has the concept of a "lost device" for cases like that. Whenever the video memory content is lost, the device becomes unusable, the app has to reset it and reload all resources. This hands the responibility for restoring the 3D rendering over to the app, which knows best where to get the resources from(load from disk, system memory or whatever). Now OpenGL doesn't have that, apps rely on opengl to restore their textures. However, it might be an option to add an extension which allows apps to tell the GL implementation that it can deal with lost resources. If non-game apps like Compiz support this, it would be enough to improve the suspend performance considerably. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On May 19, 08 20:52:49 +0100, Dave Airlie wrote: > Now I would be willing to provide a drm tuneable sorta like memory > overcommit that could be used on embedded systems and basically says I've > designed my system so I never need suspend/resume and I really udnerstand > what I'm doing, so don't ensure I have backing store for VRAM allocations. > This would never be the default. At least on suspend to RAM many GPUs can probably be programmed to keep VRAM contents alive. In that case you wouldn't have to save that data as well. Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 08:52:49PM +0100, Dave Airlie wrote: > Now I would be willing to provide a drm tuneable sorta like memory > overcommit that could be used on embedded systems and basically says I've > designed my system so I never need suspend/resume and I really udnerstand > what I'm doing, so don't ensure I have backing store for VRAM allocations. > This would never be the default. Right. 'I don't have swap, and I don't lose memory content across deep sleep anyway.' Cheers, Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
Dave Airlie wrote: >> 1) The ideal thing would be for the card contents to be quickly copied >> to backing-store and suspend is done. >> However, this requires pinning as much physical pages as there is VRAM. >> >> 2) The other approach is to have a backing object of some sort, either a >> list of swap-entries or perhaps a gem object. >> The gem object would, at the point of suspend, either be paged out or >> unpopulated which means (provided that the swap sub-system is up at the >> suspend point) there will be heavy disk-access and the operation might >> fail due to a shortage of either swap space or physical memory for the >> swap system bookkeeping. >> >> Just want to know what's the general opinion here. Are the VRAM card >> developers planning to back all VRAM objects with pinned physical pages, >> or are we looking at approach 2) which might fail? >> >> > > By default for a laptop system you *have* to have swappable backing store > for everything in VRAM preallocated, not pinned, but available. > The thing is, to guarantee success we need to pin. The second best approach is to have swap-entries pre-allocated, but if the swapping system fails to allocate pages for internal data structures att swapout time, it might still fail. At that time, the current swapping code actually frees the swap-entry and tries to realloc it. I'm not sure why it's doing that, but it probably has a good reason. The third best approach is to have gem objects allocated and ready. However, at the time of swapout, these are probably either unpopulated with pages, or paged out. Unpopulated is basically the same as not having alloced anything at all. Last but not least, we may have systems without swap, as Jakob pointed out. In that case we will probably fail a lot. > Failing suspend is not the answer, as user closes laptop lid, and sticks > it in bag, he doesn't expect it not to suspend because he has blender and > compiz running or whatever. So we have to fail on object allocation if we > have no backing store available. > I think unless we pin, we have no _reliable_ backing store. However, allocating swap entries is a way to have fairly reliable backing store, but that is a bit rude to other kernel resources that might also need swap space to be able to suspend. > Now I would be willing to provide a drm tuneable sorta like memory > overcommit that could be used on embedded systems and basically says I've > designed my system so I never need suspend/resume and I really udnerstand > what I'm doing, so don't ensure I have backing store for VRAM allocations. > This would never be the default. > Note this is not a crusade against backing store :). Although I must say I think _pinned_ backing store should not really be considered for VRAM. Perhaps pre-allocating swap entries is as good as it gets, but I think we should have the option to defer that pre-allocation to prepare-for-suspend for the typical desktop user. We also need to have some swapping code written up and exported from the main kernel. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
> > 1) The ideal thing would be for the card contents to be quickly copied > to backing-store and suspend is done. > However, this requires pinning as much physical pages as there is VRAM. > > 2) The other approach is to have a backing object of some sort, either a > list of swap-entries or perhaps a gem object. > The gem object would, at the point of suspend, either be paged out or > unpopulated which means (provided that the swap sub-system is up at the > suspend point) there will be heavy disk-access and the operation might > fail due to a shortage of either swap space or physical memory for the > swap system bookkeeping. > > Just want to know what's the general opinion here. Are the VRAM card > developers planning to back all VRAM objects with pinned physical pages, > or are we looking at approach 2) which might fail? > By default for a laptop system you *have* to have swappable backing store for everything in VRAM preallocated, not pinned, but available. Failing suspend is not the answer, as user closes laptop lid, and sticks it in bag, he doesn't expect it not to suspend because he has blender and compiz running or whatever. So we have to fail on object allocation if we have no backing store available. Now I would be willing to provide a drm tuneable sorta like memory overcommit that could be used on embedded systems and basically says I've designed my system so I never need suspend/resume and I really udnerstand what I'm doing, so don't ensure I have backing store for VRAM allocations. This would never be the default. Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, 19 May 2008 18:55:46 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote: > Yes this is a way to do the actual implementation. > But we will always have situations where writing to swap may fail. > Systems without swap, systems low on swap, and systems without enough > physical memory to manage the swap area. > > We can try to reserve all the swap we need for graphics and be rude to > other system resources, but I think the best approach is simply to > allocate what we need at suspend - prepare time. If we're out of > swap-space we need to cancel suspend. > I think there is a lack in kernel interface we should have a way to tell the kernel okay we will need 1Go (of whatever storage and we can use temporary small buffer to evict memory to this storage) to suspend then it's up to the kernel to either find this Go or to fail and abord suspend. We likely are the only device writter needing so much memory so obviously we should talk to kernel side as they should have ask us what is needed for proper video suspend. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
Jerome Glisse wrote: > On Mon, 19 May 2008 16:25:13 +0200 > "Jakob Bornecrantz" <[EMAIL PROTECTED]> wrote: > > >> On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: >> >>> On Mon, 19 May 2008 15:03:50 +0200 >>> Thomas Hellström <[EMAIL PROTECTED]> wrote: >>> >>> Hi! Parallell to the memory manager discussion, I think we need to revisit the case of what happens when a VRAM driver is suspending to memory. 1) The ideal thing would be for the card contents to be quickly copied to backing-store and suspend is done. However, this requires pinning as much physical pages as there is VRAM. 2) The other approach is to have a backing object of some sort, either a list of swap-entries or perhaps a gem object. The gem object would, at the point of suspend, either be paged out or unpopulated which means (provided that the swap sub-system is up at the suspend point) there will be heavy disk-access and the operation might fail due to a shortage of either swap space or physical memory for the swap system bookkeeping. Just want to know what's the general opinion here. Are the VRAM card developers planning to back all VRAM objects with pinned physical pages, or are we looking at approach 2) which might fail? /Thomas >>> The ideal things, from my POV, is to ask to kernel to reserve swap space >>> each time we allocate a buffer, if we ran out of swap space or whatever >>> backing store the kernel can propose then we should fail buffer allocation >>> even if we still have vram available. Idea being that once we migrate out >>> stuff we know that there won't be failure to give us space to save things. >>> Anothers things is to add a hint from userspace which tell if we can >>> drop buffer content, i think we can use such hint for cmd buffer or >>> others temporary buffer we know of, won't save much but still might >>> help to save somebandwidth. >>> >>> Of course this need that kernel provide us an interface for such things. >>> If i am right shmem is already talking with kernel about swap space. >>> >>> Cheers, >>> Jerome Glisse >>> >> The biggest question is where we can write or read pages to swap at >> suspend to RAM and resume from RAM under all occasions. >> >> If not we have no other option then to have pages as backing store if >> we want to support suspend to ram for cards with VRAM that turn the >> ram of at suspend to RAM. >> >> The problem is that no solution is good. >> >> Cheers Jakob. >> > > The idea i did have in mind was a small scratch area where i dma from > vram. Then i use a kernel interface to write to swap area (could be > disk or flash or whatever other storage we can think of). So basicly > you loop using the scratch area until you have moved all vram. > > Cheers, > Jerome Glisse > Yes this is a way to do the actual implementation. But we will always have situations where writing to swap may fail. Systems without swap, systems low on swap, and systems without enough physical memory to manage the swap area. We can try to reserve all the swap we need for graphics and be rude to other system resources, but I think the best approach is simply to allocate what we need at suspend - prepare time. If we're out of swap-space we need to cancel suspend. /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 5:03 PM, Jakob Bornecrantz <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell > <[EMAIL PROTECTED]> wrote: >>> The biggest question is where we can write or read pages to swap at >>> suspend to RAM and resume from RAM under all occasions. >>> >>> If not we have no other option then to have pages as backing store if >>> we want to support suspend to ram for cards with VRAM that turn the >>> ram of at suspend to RAM. >> >> It should be possible. The two-phased approach that seems to be >> ascendent would give all the opportunity you need in the "prepare" >> phase, while the full system is still running. >> >> http://lwn.net/Articles/274008/ >> >> Keith > > Yes a two step program can work. At prepare we turn on backing storage > mode for VRAM, that is all buffers in VRAM gain backing storage and > all buffers that are moved to VRAM keep their pages. Then at suspend > we copy everything down from VRAM and turn the card off. > > The problem is that after prepare things must still work as before so > clients can still render so we can't copy pages down then. I also > don't think we can count on swap being around at the call to suspend. > Heck a system might not even have swap. So the whole idea is that we have a backing store mode that is only used between prepare and suspend to make sure that buffers in VRAM can be saved. Some updates, allocating 1GB plus of memory might not work at prepare, for that matter allocating 64-256mb might not go that well over with the kernel developers for that matter. So the idea is that at prepare we evict all buffers that we can from VRAM and if we feel like it AGP too. If the driver is using a superioctl we can also temporary stop all submissions through it and wait on the last fence to be sure we can move all buffers out. That should only leave the cmdbuffer(s) and scanout buffer(s) left. For the buffers that are in VRAM we now allocate backing stores, this should not fail since we have just unpinned a lot of memory. Should this fail we are out of luck and can not suspend. After that we turn on backing store mode and unlock the superioctl so that clients can use it. Since the card should still work after prepare from what I can understand. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell <[EMAIL PROTECTED]> wrote: >> The biggest question is where we can write or read pages to swap at >> suspend to RAM and resume from RAM under all occasions. >> >> If not we have no other option then to have pages as backing store if >> we want to support suspend to ram for cards with VRAM that turn the >> ram of at suspend to RAM. > > It should be possible. The two-phased approach that seems to be > ascendent would give all the opportunity you need in the "prepare" > phase, while the full system is still running. > > http://lwn.net/Articles/274008/ > > Keith Yes a two step program can work. At prepare we turn on backing storage mode for VRAM, that is all buffers in VRAM gain backing storage and all buffers that are moved to VRAM keep their pages. Then at suspend we copy everything down from VRAM and turn the card off. The problem is that after prepare things must still work as before so clients can still render so we can't copy pages down then. I also don't think we can count on swap being around at the call to suspend. Heck a system might not even have swap. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, 19 May 2008 16:25:13 +0200 "Jakob Bornecrantz" <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > On Mon, 19 May 2008 15:03:50 +0200 > > Thomas Hellström <[EMAIL PROTECTED]> wrote: > > > >> Hi! > >> > >> Parallell to the memory manager discussion, I think we need to revisit > >> the case of what happens when a > >> VRAM driver is suspending to memory. > >> > >> 1) The ideal thing would be for the card contents to be quickly copied > >> to backing-store and suspend is done. > >> However, this requires pinning as much physical pages as there is VRAM. > >> > >> 2) The other approach is to have a backing object of some sort, either a > >> list of swap-entries or perhaps a gem object. > >> The gem object would, at the point of suspend, either be paged out or > >> unpopulated which means (provided that the swap sub-system is up at the > >> suspend point) there will be heavy disk-access and the operation might > >> fail due to a shortage of either swap space or physical memory for the > >> swap system bookkeeping. > >> > >> Just want to know what's the general opinion here. Are the VRAM card > >> developers planning to back all VRAM objects with pinned physical pages, > >> or are we looking at approach 2) which might fail? > >> > >> /Thomas > > > > The ideal things, from my POV, is to ask to kernel to reserve swap space > > each time we allocate a buffer, if we ran out of swap space or whatever > > backing store the kernel can propose then we should fail buffer allocation > > even if we still have vram available. Idea being that once we migrate out > > stuff we know that there won't be failure to give us space to save things. > > Anothers things is to add a hint from userspace which tell if we can > > drop buffer content, i think we can use such hint for cmd buffer or > > others temporary buffer we know of, won't save much but still might > > help to save somebandwidth. > > > > Of course this need that kernel provide us an interface for such things. > > If i am right shmem is already talking with kernel about swap space. > > > > Cheers, > > Jerome Glisse > > The biggest question is where we can write or read pages to swap at > suspend to RAM and resume from RAM under all occasions. > > If not we have no other option then to have pages as backing store if > we want to support suspend to ram for cards with VRAM that turn the > ram of at suspend to RAM. > > The problem is that no solution is good. > > Cheers Jakob. The idea i did have in mind was a small scratch area where i dma from vram. Then i use a kernel interface to write to swap area (could be disk or flash or whatever other storage we can think of). So basicly you loop using the scratch area until you have moved all vram. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > On Mon, 19 May 2008 15:03:50 +0200 > Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> Hi! >> >> Parallell to the memory manager discussion, I think we need to revisit >> the case of what happens when a >> VRAM driver is suspending to memory. >> >> 1) The ideal thing would be for the card contents to be quickly copied >> to backing-store and suspend is done. >> However, this requires pinning as much physical pages as there is VRAM. >> >> 2) The other approach is to have a backing object of some sort, either a >> list of swap-entries or perhaps a gem object. >> The gem object would, at the point of suspend, either be paged out or >> unpopulated which means (provided that the swap sub-system is up at the >> suspend point) there will be heavy disk-access and the operation might >> fail due to a shortage of either swap space or physical memory for the >> swap system bookkeeping. >> >> Just want to know what's the general opinion here. Are the VRAM card >> developers planning to back all VRAM objects with pinned physical pages, >> or are we looking at approach 2) which might fail? >> >> /Thomas > > The ideal things, from my POV, is to ask to kernel to reserve swap space > each time we allocate a buffer, if we ran out of swap space or whatever > backing store the kernel can propose then we should fail buffer allocation > even if we still have vram available. Idea being that once we migrate out > stuff we know that there won't be failure to give us space to save things. > Anothers things is to add a hint from userspace which tell if we can > drop buffer content, i think we can use such hint for cmd buffer or > others temporary buffer we know of, won't save much but still might > help to save somebandwidth. > > Of course this need that kernel provide us an interface for such things. > If i am right shmem is already talking with kernel about swap space. > > Cheers, > Jerome Glisse The biggest question is where we can write or read pages to swap at suspend to RAM and resume from RAM under all occasions. If not we have no other option then to have pages as backing store if we want to support suspend to ram for cards with VRAM that turn the ram of at suspend to RAM. The problem is that no solution is good. Cheers Jakob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On Mon, 19 May 2008 15:03:50 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote: > Hi! > > Parallell to the memory manager discussion, I think we need to revisit > the case of what happens when a > VRAM driver is suspending to memory. > > 1) The ideal thing would be for the card contents to be quickly copied > to backing-store and suspend is done. > However, this requires pinning as much physical pages as there is VRAM. > > 2) The other approach is to have a backing object of some sort, either a > list of swap-entries or perhaps a gem object. > The gem object would, at the point of suspend, either be paged out or > unpopulated which means (provided that the swap sub-system is up at the > suspend point) there will be heavy disk-access and the operation might > fail due to a shortage of either swap space or physical memory for the > swap system bookkeeping. > > Just want to know what's the general opinion here. Are the VRAM card > developers planning to back all VRAM objects with pinned physical pages, > or are we looking at approach 2) which might fail? > > /Thomas The ideal things, from my POV, is to ask to kernel to reserve swap space each time we allocate a buffer, if we ran out of swap space or whatever backing store the kernel can propose then we should fail buffer allocation even if we still have vram available. Idea being that once we migrate out stuff we know that there won't be failure to give us space to save things. Anothers things is to add a hint from userspace which tell if we can drop buffer content, i think we can use such hint for cmd buffer or others temporary buffer we know of, won't save much but still might help to save somebandwidth. Of course this need that kernel provide us an interface for such things. If i am right shmem is already talking with kernel about swap space. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
