Re: radeon-pre-2

[Linus Torvalds]

On Sun, 12 Sep 2004, Dave Airlie wrote:
> 
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.

Now, how much do you actually really need to restore/save?

Yes, intelligent restore/save means that there needs to be independent
memory management, but I thought that was the long-term plan _anyway_, no?  
And once you have reasonably intelligent memory management, you really
only need to save/restore the engine state, if even that (ie it should be
enough to just "idle" the engine).

Now, I'll agree that getting a good MM that solves peoples issues is a
huge problem. Much harder that some little locks. But on the other hand,
it really should be able to be largely card-agnostic, I sincerely hope.

And once you have some way to manage memory allocations between different
clients, saving/restoring card state really shouldn't be problematic. You 
make the rule be that everybody has to be able to re-create their caches 
(as with the locks, the cache manager would obviously have to have a 
callback), and you should never be in the position where you have to 
really save/restore any video memory contents at all.

(Yes, and if your working set ends up being bigger than your video ram, 
you won't perform well, but that's pretty fundamental regardless of number 
of clients or how they communicate).

The MM is still fairly complex, especially wrt areas that are "busy"  
(the client may be able to re-create them, but if the currently executing
_engine_ has pointers to it, the cache obviously can't be thrown away).  

Many of those things might be simplified by having fairly strict rules
("you can do video memory garbage collection only when the engine is
idle"), otherwise you'll need to have some complex infrastructure to keep
track of which areas are used by which commands...

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/