Xorg 7.0-rc1 and EXA (radeon 9200)

[Stephane Marchesin]

On Thu, Oct 27, 2005 at 08:10:13AM +1000, Benjamin Herrenschmidt wrote:
> 
> > 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.

So you are hardcoding one more limitation in the radeon ddx. Just like the
pixmap/texture memory split which was unnecessary and is now a pain to
remove.

Stephane