Xorg 7.0-rc1 and EXA (radeon 9200)

[Benjamin Herrenschmidt]

> I think you're making a mistake here. It's not about trying to
> prioritize one over the other, but trying to get both cooperate.
> As you probably now, this is major pain for radeon dri developers, 
> since the radeon ddx assumes in lots of places that it's the only one 
> in the world and takes no care when overwriting stuff.

I think the problem is irrelevant and the surface allocator completely
unnecessary. The reason ? Heh, it's called the DRM lock :) You need to
have the lock to access the hardware. Thus you can prefectly assume that
you own the surface registers when you own the lock. Period. As simple
as that.

Now, for clients who don't have direct register access but with fb
access, well, they definitely need some way to define surfaces for fb
access, thus some kind of ioctl must remain for these.

In fact, it's easy to do something like: limit the current virtual
surface allocator to, let's say, 5 physical surface registers for use by
those clients. Let the 3 other ones alone. They can be used directly
with any client that has direct register access, like X, for performance
reasons. They don't have to be reserved permanently or context switched
as there is no problem losing their content while losing the DRM lock,
easy enough to re-establish them when needed.

Ben.