Hmm. But at least increasing the AGP size shouldn't be much of a problem, right?implications. What if one process removes the backing from a region of the AGP aperture a the same instant another process tries to texture from that range? Random memory reads? System crash? Dunno...
This just can't heppen, no sharing of AGP space, right?
Video memory and AGP memory is accessed by all direct rendering processes and the X-server.
I'm thinking something like this:
client runs out of texture size -> requests from a central instance (say, X Server) GART size to be increased -> X Server tells agpgart to increase mapped GART size -> if successful, agpgart tells drm/drms (can there be more than one) new valid GART range, and X Server tells all dri clients new valid range.
Reclaiming could be done similarly, though maybe must be triggered by some daemon from time to time?
-> Someone requests GART size to be decreased -> X Server asks dri clients to cope with lower GART size (and if one client says no because it still has textures bound in that space abort) -> asks agpgart to decrease GART size -> agpgart asks drm drivers to decrease GART size -> drm drivers need to make sure all commands they have already checked for valid offsets and sent to the graphic card have been processed (I think that's a problem, as some texture offset could still be used later), then give their ok to agpgart -> agpgart reduces mapped size.
Looks like a lot could go wrong though, and I'm not even sure it makes sense...
And some crazy dri client holding that 1x1 texture right at 256MB would still be able to make it impossible to decrease gart size again, though that shouldn't be much of a problem.
Roland
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
