[Fwd: Re: CVS Update: xc (branch: trunk)]

Thomas Winischhofer thomas at winischhofer.net
Sat Jul 9 07:52:09 PDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Smirl wrote:
> On 7/9/05, Thomas Winischhofer <thomas at winischhofer.net> wrote:
> 
>>the registers or the card state are/were not the issue here. This has
>>worked for ages (well, at least with my drivers).
> 
> 
> I didn't say there were any problems, those were just some quick
> checks to make sure everything is working right with EXA. EXA is using
> some more registers, right?


Yes, but these are the same as for XAA... for most cards, I would very
much assume...


> So, for example, they need to be added to the list of registers being
> saved/restored in the radeon driver. I also suspend that radeonfb in
> fbconsole mode is going to stomp on some registers EXA is using.


Ok, just to be complete (even if that might not be an issue): You can't
restore ALL registers on all cards. There are read-only registers, there
are ring buffers and their registers (which can't just be restored, but
restoring requires a reset of the command buffer...) and the like...


> Resetting the card from a console session is a good way to make sure
> you are restoring all of the registers you need to.


So X must assume "everything is different" on every VT switch?

Surprises me. Does ANY driver save the entire card state in "EnterVT"?

So, does the radeon driver restore the display mode (and other
registers) correctly, when

1) you start X
2) switch away to another VT
3) start radeonfb and fbcon
4) return to X
5) return to another vt.

What happens? (Hm, might work though because 2.6 issues a set_par)


>>>Of course all of these different combos need to work with suspend/resume too.
>>
>>I fail to see how vram preservation is the driver's responsibility.
> 
> 
> In the drivers I work with no one is saving vram on suspend/resume.
> Instead all of the drivers are able to reconstruct their state. The
> exception to this is DRI/DRM which doesn't work with suspend/resume.
> EXA needs to be able to rebuild all of it's state in VRAM on resume.

Easy... the pixmaps are in system memory, and that is saved somewhere,
or not...?

> 
> EXA also needs to coordinate it's VRAM use with DRM. I haven't been
> following things so I don't know if that has been taken care of.

That's under discussion. For now, it has a memory manager of its own
which uses RAM that the DRM/DRI doesn't use. Driver callbacks (for
handing memory allocation requests through to the DRM) have been
proposed. This is, however, not implemented yet.

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz+SZzydIRAktyUcRAuJsAKDKSp9fB5eQgZgVJbCNvrIbt6OzYQCdF3Pk
r2vcru9GT4/MGdTs+X3Kdtk=
=Qp8r
-----END PGP SIGNATURE-----



More information about the xorg mailing list