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 leas
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
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 a
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
>
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 s
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
conce
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
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 doi
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 o
>
> 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 per
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 ma
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:
>>>
>>>
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
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 supp
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 manage
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 sus
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 qu
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 phy
18 matches
Mail list logo
